My teammate, Kirk Evans, has a good blog about SharePoint development. Not just your typical stuff about using SharePoint Designer to create master pages and portals. His blog really covers it from a developers perspective because he’s really a .NET coder first, SharePoint development guru second.
A couple of times we had conversations about how we unit testing is great but if only we had a better story around it for SharePoint developers. With the upcoming Visual Studio 2010 SP1 due out soon, we will have the ability to provide better unit testing support for SharePoint developer using Visual Studio.
The Visual Studio Team Test blog posted a good article back in December about how VS 2010 SP1 will enable basic support for unit testing. Even though SharePoint 2010 is the latest version, its target .NET framework is 3.5, not 4. That’s because when we create our platform, they are typically built on what’s released, not what’s going to be released. With VS 2010, you will have to re-target your test project to .NET 3.5 and 64-bit (since SharePoint 2010 is a 64-bit platform), and you should be good to go. Of course, you really should the article if you want to know whole article (How to re-target unit-tests to .Net Framework 3.5 in VS 2010 SP1).
A big pro (in my eyes anyway) is that once your setup is done, you can work fast. Setting up your environment for a test (if you're doing it through the UI) is a pain. It takes a long time. For example, if you need to create your columns, then your content type though the UI every time you make a change to code that uses it, you'll lose a lot of time. Even more so if your test fails and you need to delete your content type because you broke something. Going with unit tests / fake SharePoint objects, you'll be able to do that in no time, plus you'll quickly get a better understanding of how the SharePoint objects work.
<a href="www.ubwebs.com/">Web Application Development</a>
By using IntelliTrace, you can determine not only the current state of your application but also events that occurred in the past and the context in which they occurred. You can navigate back and forth to various points in time in your program where events of interest were recorded and review the states and values of variables at each point. You can also save the debugging session into a file that you can reload, and perform post-crash debugging. For more information, see Debugging with IntelliTrace.