Greg Young started an interesting discussion about Unit Testing BizTalk solutions; some good things to consider are brought on. In general, I agree with Greg that testing BizTalk solutions isn't always easy, in particular because of dependencies and because of the level at which BizTalk solutions are created (it is certainly a higher abstraction level than regular C# code, for example). That, and the fact that the BizTalk engines are fairly complex constructs, make it harder to test pieces of your solution in isolation, though it is by no means impossible.

One point I wanted to take back from the discussion is Greg's comment that testing Schemas isn't much of a problem and you're probably going to get those on integration testing. That is true if you're dealing with simple schemas, but if you're creating complex Flat File schemas and doing things like debatching and a few of the other advanced things that BizTalk schemas support, then being able to test your schemas in isolation in a repeatable, automated fashion is a real blessing. Whether you want to call this unit testing or not is open for debate, I'm sure, but it is a good thing none the less.

At a higher level, Greg does bring a pretty significant question about whether it is possible to do Agile development when using BizTalk. I'd sat it is certainly harder than in other disciplines and with other tools, but not necessarily because of the tool itself. One of the real issues here is the fact that Application Integration (particularly on big projects) requires a somewhat larger investent in Architecture up-front, because of the complexity of the issues involved and sometimes because integration projects are composed of three or more providers (i.e. different companies) collaborating with the customer to implement the required solution. This does require that you have a more significant shared understanding of the problem at hand up-front and that some key issues are covered right from the start.

Notice I'm not advocating a waterfall model, I'm just saying that some serious understanding needs to be done at the start to ensure everyone is working towards the same goal. There are many ways you can this done, without bringing the whole project to a stop while the entire requirement analysis is done. For example, this initial phase is a great time to prototype  parts of the solution, create initial versions of shared schemas, and explore potential solutions to some of the issues the project has.

On some of the integration projects I've worked on doing this has been a key to the success of the project, even allowing us to work after that in a far more agile fashion while minimizing dependencies and even allowing us to complete the BizTalk part of the solution well in advanced to other parts of the whole integration project.

I'm looking forward to exploring if some of the Agile Architecture ideas can be used to make this initial part of the project more dynamic, as well.