TDD for BizTalk
TDD is the hot new topic. Actually, it has been around in one form or another for several years. With the release of Visual Studio 2005, I expect to become even more of a hot topic. When I introduce TDD to professional developers in my shop, they tend to think of it as a drag at first. This is when I usually ask them how they developed their last personal project. They always talk about how they wrote on feature, and made sure that worked, and then moved onto the next piece in a very organic way. They grew the architecture as needed, and refactored to streamline the code. They didn't sit down and write 50 pages of technical documentation (although they may have drawn some big boxes and arrows.) TDD is merely writing tests to validate the features you want to implement, before you write the code. The green light of TDD is what tells you when you are done. Which is hard for some developers to know. We call them 'gold-platers' around these parts.
Test Driven Design is a great tool to use on your development team. We use it my shop, in one form or another. This process does leave you with a complete suite of tests to support your code. The true soul of TDD though is the concept of incremental design. By writing a test for a specific business rule or requirement (sometimes many tests), and then writing JUST ENOUGH code to complete that test, you will end up with a much tighter and appropriate design. The toughest part is building something before you truly need it. Don't confuse this however with the use of patterns to build in flexibility that might be required of the system; such as the provider model seen in many parts of ASP.NET 2.0.
This post isn't really about TDD in software, and I may not be the highest authority on it to begin with. The challenge with our shop is the big part of software that can't be supported by TDD tools (ie nunit). For example, it has been hard to automate and drive out our design of BizTalk orchestrations without any sort of normal TDD tool. This is where BizUnit comes in. It gives you the same toolset for BizTalk that you would have with your normal business code. The best way to approach this is to consider your processes in BTS as black boxes. Then you can use BizUnit to submit messages, and validate their results. Version 2 was just released at its workspace. I look forward to upgrading to version two. We are at a point in a project at the shop where there will be some significant BTS work, and this will make it much nicer.
-bhp
Test Driven Design is a great tool to use on your development team. We use it my shop, in one form or another. This process does leave you with a complete suite of tests to support your code. The true soul of TDD though is the concept of incremental design. By writing a test for a specific business rule or requirement (sometimes many tests), and then writing JUST ENOUGH code to complete that test, you will end up with a much tighter and appropriate design. The toughest part is building something before you truly need it. Don't confuse this however with the use of patterns to build in flexibility that might be required of the system; such as the provider model seen in many parts of ASP.NET 2.0.
This post isn't really about TDD in software, and I may not be the highest authority on it to begin with. The challenge with our shop is the big part of software that can't be supported by TDD tools (ie nunit). For example, it has been hard to automate and drive out our design of BizTalk orchestrations without any sort of normal TDD tool. This is where BizUnit comes in. It gives you the same toolset for BizTalk that you would have with your normal business code. The best way to approach this is to consider your processes in BTS as black boxes. Then you can use BizUnit to submit messages, and validate their results. Version 2 was just released at its workspace. I look forward to upgrading to version two. We are at a point in a project at the shop where there will be some significant BTS work, and this will make it much nicer.
-bhp
Comments