First: Your not going to be writing unit tests for the SPSite.Exists method as you really have to make the call that Microsoft already did this.

Second: You actually want to write some code, a method, that will in it's logic make a call to the SPSite.Exists method to determine the actions for that method. To make this a unit test you will need to mock out the call, which using TypeMock is actually pretty simple.

Isolate.WhenCalled(() => SPSite.Exists(new Uri(”http://www.21apps.com”))).WillReturn(true);

Here I've just told Typmock to always return true when the SPSite.Exists is called within my method. You can extend this with checks on the parameters if you wanted as well.

Regarding the SPSecurity.RunWithElevatedPrivileges this does present a challenge, but doing TDD should help as you really drive it from being testable. This often leads to you coding and testing the methods outside of the SPSecurity.RunWithElevatedPrivileges, i.e. less anonymous delegates, and also designing you classes so that any elevated calls are contained in very focused code wrapped in your own classes.
This is probably an area that I should do some more blog posts on.

[Cross posted on  SharePointDevWiki.com] Think this is the ……

TDD == an approach to writing your code that starts with the unit test first.

What you are talking about is the scope of the unit tests, in the P&P project they make a call as to which elements of the code base are demeed appropriate for unit testing.

The problem you have with unit testing workflow code is that workflow is basically infratructure and in order to unit test your code there is just way too much to mock out/fake in order to make it a Unit test. This is why most projects adopt automated integration testing to prove the workflow code. This is an area however that I think could do with further investigations and guidance on how to best test your workflow code.

You agree we can't forgo testing, and here we mean unit testing as well as all the other kinds. The cost of producing the unit tests will be similar whether done with TDD or done afterwards (many argue that with TDD it will be less).

Why then would Sahil want to make such a big thing about a specific developer approach to the generation of testable code? As I stated above I think the problem comes with peoples lack of understanding regards to TDD and also the sometime evangelical preaching that some in the community do for its use.

Now the question of how much code do you unit test and if you would be better servered through the use of more Integration tests and automation is a valid. And you will find that in SP projects (like the ones Sahil refers) there is likely to be a different mix of unit/integration tests.

But this is nothing to do with TDD – hence my post.