What techniques do you use to debug/test your SharePoint Timer Jobs?

Question

I have developed a number of SharePoint Timer Jobs and they are always a bit more painful to debug and test than other areas of SharePoint.

I was wondering what tools/techniques other people use to do their debugging and testing of SharePoint Timer Jobs?

Answer 1

My biggest issue with testing timer jobs was getting the job to start so that I could debug it. It seems like I when I reset the timer service whenever I deployed new code and when the service restarted, even though I had my job to run every minute, sometimes it would take up to an hour for it to "catch up" and get around to running my timer job.

I think the best way is to make your timer job business logic code seperate from spjobdefinition and build unit tests for it. That way you do most of your testing using unit tests and when you are happy that it is working correctly, build the spjobdefinition that just calls your business logic code. That way you have less testing in which you have to depend on the timer service.

Answer 2

You can use

System.Diagnostics.Debugger.Launch();

to attach a debugger (Visual Studio) instead of attaching the timer job in VS.

Also i tend to use DebugView alot to just write out asserts or messages like

System.Diagnostics.WriteLine("sometext","MYCATEGORY");

Another tip for testing is to encapsulate the logic in its own class. Then you can test (and unit test) the code first in for example a console application. Then you wont have to wait for timer job to execute etc.

hth Anders Rask

Helpful references Creating, Deploying and Debugging Custom Timer Jobs

Answer 3

A couple of small things you have probably already considered.

Stop and restart the Timer service as part of the pre-build event to release any of your solution's GAC dlls.

Rather than attaching to the process using the debugger I prefer to use System.Diagnostics.Debugger.Break();

For other SharePoint related guidelines, check out our free SharePoint Development Guidelines.

Answer 4

As both Anders and Steve have pointed out, write the main processing of your timer job in a separate Class Library. For debugging "wrap" a Console App around it, and when you're happy wrap it in a timer job. If at a later point you want to debug, you use your Console App again - F5 and there you go.

On a related note, check out SharePoint Layered Architecture App here on SharePointOverflow.com