Benefits of Test-Driven Development

When I have tried out test-driven development I have really liked it. It just seems easier for me to concentrate. In a typical, non-TDD situation, my thoughts try to map the use cases or requirements to my code, and it does not work very well. But writing tests kind of sits in the middle.

While writing tests, I can focus on just formalizing what needs to be done. I eventually get to the point where I can say, "If all these tests pass, then I am comfortable that the feature passes." Then, when I go to writing code, I can just focus on one test at a time. I hardly even have to think about the use cases at that point, and things just flow.

I watched a good webcast on TDD concepts and how to do some TDD in BizTalk Server (here). Some thoughts:

• Repeatable tests - I have heard many developers say, "Fixing one thing breaks things elsewhere." One of the hardest things about changing others' code or refactoring my own code is that I may be inadvertently making changes that will cause problems elsewhere. By running the tests with every build, I immediately see whether I broke anything--and I don't have to wait for testers or users to find bugs that I may have introduced. Automated testing also ensures
• Feedback - How many times have project managers asked me how far I am to completing a feature? My standard answers are 25%, 50%, or 100%. Percentages always seem to make my PMs happy. But even if I am "done" and say 100%, have I done integration testing, end-to-end use case testing? Probably not. Maybe I should say 100%*. But with TDD, the PM (or managers, or clients) could look at an auto-generated report of the most recent test results. Then they could see whatever percentage of tests for that feature have passed or failed.
• Incremental Design - KISS, DRY, The Simplest Thing That Could Possibly Work. TDD pushes me to write the minimum number of tests to make the feature work, and in turn, the least amount of code to make the tests pass. No over-design or scope creep on my part.
• Executable Documentation - If I use friendly names or description attributes for my test methods, they become a pretty good source of documentation. By scanning tests, it quickly becomes apparent what the code is supposed to do.

SharePoint Test-Driven Development Resources

I have been tasked with figuring out how to integrate test-driven development into my company's new development process. One of the important points is how to do TDD with SharePoint development, which I am not too familiar with. The best I could come up was creating an interface-based service layer around SharePoint. That way, you could have stub or fake classes that implement the interface.
After looking at some mocking frameworks, I realized you could have a manager class that is not interface based and mock the manager when testing. I have a long way to go, but based on the list of articles below, I think I am on the right track. Any suggestions are appreciated.

• Corporate Coder : TDD development with Sharepoint 2007
• Corporate Coder : More thoughts on Test Driven Development with Sharepoint 2007
• Model-View-Presenter Pattern with SharePoint Web Parts - Fear and Loathing
• "Test Driven" SharePoint Development
• OneOfSix - Creating an NUnit base test class for SharePoint applications
• OneOfSix - Creating an NUnit base test class for SharePoint applications: Part 2
• White Paper by Andrew Woodward
  

Line of Business Adapter Pack and SDK Poster Released

The BizTalk product group has release a new poster for the LOB Adapter Pack and WCF Adapter SDK
.

It looks like the SDK is still under the BizTalk team, even though it is designed to be used outside of BizTalk. The screenshots below show that you can use it to access LOB systems from SharePoint, BizTalk, IIS, SQL Server, and general .NET code.

The SDK utilizes WCF and presents a uniform view no matter the backend system, as long as an adapter has been written for the system.

Convert an XML string to an XMLNode using XmlDocumentFragment

In an orchestration, I was gathering messages representing Order Line Items. Once they were gathered, I would create the Order message, then inject the Order Line Items XML into the Order XML using a helper method. I did not want to create the Order message first, because I needed certain properties that I could only calculate after I had received all the Order Line Items (properties like NumberOfLines and OrderTotal).

To do this, I needed to store the Order Line Items as I received them, until I was ready to use them. I could not use XmlElement because it is not serializable. I tried using strings by storing the OuterXml property of the XmlElement, but I did not know how to convert the XML string back into XML. I could create a node, but it would not match the XmlDocument representing the Order. I found a good tip on a forum post at http://forums.asp.net/p/310492/310527.aspx suggesting the use of XmlDocumentFragment, which inherits from XmlNode (as do XmlElement and XmlDocument):


XmlDocumentFragment fragment = xmlDoc.CreateDocumentFragment();
fragment.InnerXml = xmlString;
parentNode.AppendChild(fragment);


Security Issues with IIS, Authentication Providers, HTTP 401 status codes

We could not authenticate to IIS, except from the local machine. Even basic authentication would send back 401.1 and 401.2 HTTP status codes (I checked this by examining the IIS logs). 401.1 is invalid username/password, but 401.2 is login failed due to server configuration. A coworker helped me with the following:

1. Start a command prompt, then navigate to the C:\Inetpub\Adminscripts folderwhere the adsutil.vbs located.
2. Check the authentication providers with this in the command prompt: cscript adsutil.vbs get w3svc/NTAuthenticationProviders
3. If you get "The parameter "NTAuthenticationProviders" is not set at this node" message, then type cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"