Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Agile: BizTalk?

I have been quite bizzy this week, emerged in BizTalk. I will be posting a complete review of the course I have been taking, it is through Mark Dunn (Dunn Consulting), and the teacher is Mark Berry. I will say now that my review on the course will be quite positive.


I have run into a severe concern involving BizTalk in an agile environment. It really does not seem to be very testable and I have always had the notion when dealing with things in an agile environment that if I can’t test it; it doesn’t exist (is this not one of the main reasons why we don’t put business logic in the database?). I have gone through downloaded and played with BizUnit but let me tell you that the name is very misleading.


BizUnit does not appear to be for unit testing, it is for functional testing.  It does however seem to do a fairly good job with functional testing, and it is fairly flexible with setup. Kevin Smith has a nice example showing a basic setup for it.  It seems like a great tool for automating large parts of the QA process, unfortunately functional tests are rarely of much use to developers.


Let’s propose for a minute that we have a much more complex orchestration that is mainly handled internally to BizTalk. We would give it a known input, let it churn for a while then check its known output. There are a couple of issues here (most can be applied to functional testing as a whole which is why we unit test).


1)      This is testing our functional specification, although it has tested our orchestration, maps, components, etc the focus of the test is how the data eventually comes out (i.e. file, msmq, database, etc) and the format that the data came in.


2)      This test will be SLOW


3)      Telling me that the test failed doesn’t really help me in fixing the problem


4)      This test is HIGHLY dependent upon configuration as opposed to more static items such as the orchestration logic


5)      The test could quite likely will fail due to a bug in another area, such as a foreign data source not returning proper data


6)      There is no good way to mock data from other repositories without completely changing the process.


I also admit that I am very new to the technology; these are my first impressions from 36 hours of immersion and some reading up on the web. I am very interested in hearing the opinions of others in agile environments that have brought this technology in.

This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

9 Responses to Agile: BizTalk?

  1. Interesting, for additional ideas about BizTalk Unit Tests see: http://whiteboardworks.com/?p=26

  2. pierre says:

    i’ve you tried BizMock?
    http://bizmock.codeplex.com/

  3. Hi,

    Interesting post and comments! I have had similar experiences. Check out my blog on a more unit testing approach for testing BizTalk artifacts (pipelines and maps) using BizUnit:

    http://geekswithblogs.net/BVeldhoen/archive/2008/10/22/unit-testing-biztalk-artifacts-using-bizunit.aspx

    I also noticed that the new version of SoapUI (2.5) allows for stubbing existing web services based on wsdl. This enables isolated testing (on i.e. a buildserver) without being dependent on those external web services. This would take care of those “foreign datasources”, provided they are web services.

  4. Mike says:

    Hi,

    Thought this might be of interest, i did a few posts describing how we do various types of testing for BizTalk projects:

    http://geekswithblogs.net/michaelstephenson/archive/2008/04/27/121687.aspx

  5. I agree that testing BizTalk can be hard.

    Not being from a coding background (just kind of stumbled into BizTalk), I have found the typical .net / coding practices doesn’t seem to fit very well with BizTalk. BizTalk is a server product that has a heave development component. This is very evident in testing.

    When I develop a BizTalk solution, I test schemas, maps, .net components, etc in a manual manner but I don’t consider this testing my BizTalk solution – since in my mind the configuration of the ports is as import as any BizTalk Artifacts.

    In order to “unit test” my end to end BizTalk solution BizUnit works very well for this. Now this might not fit the definition of unit testing, but is comes close looking at it from a BizTalk Server point of view with a unit being a process (message in – message out) scenario. From a BizTalk Server point of view, this is the smallest unit of work you can test.

    Since I have worked on about 10 different BizTalk project everyone has a different opinion on this. I was on one project in the past that told me I couldn’t run a single Orchestration since running Orchestration was considered Integration Test and not in my scope (or time bucket).

    I just wanted to throw in my 2 cents.

  6. I doubt you’ll be able to self-host the orchestration engine; it is a fairly complicated component, but hey, if you succeed, then do let us know how :)

    BizTalk itself is an extremely powerful product, but pretty complex. It’s also pretty daunting at first and “getting it” right takes a while.

    Re. BizTalk Light: Sure, it would be interesting, but since the story for BizTalk is scalability and reliability, you pay a price. BizTalk isn’t all that heavy, btw, and can really do a lot of work given a proper configuration (and I’m not talking a 10 server farm). However, my guess is that MS will try to fill that small-integration level niche with WF and the upcoming WinFX adapter framework in BTS2006 R2 (which allows you to create integration adapters on top of WCF which can be used both standalone with WCF or as BizTalk adapters).

    Re. the UI: I don’t find the UI problematic at all. Sure, it aint’s so pretty, but BTS2006 has a really nice management console, and the tools in VS are pretty good overall. BTW, you shouldn’t have to re-add references to see changes, at least I’ve never had to. However, you really need to understand the deployment and versioning story behind biztalk as well as the execution model to know how to work effectively and don’t get caught on long redeploy/restart cycles, which are productivity killers. Jon Flanders has some pretty good posts on this topic, btw, which you might want to research.

  7. Greg says:

    4- I think I have some but I will need to get into some documentation in order to determine the feasability of my thought.

    I had figured out how to do some decent testing for BRE/Maps. Schemas were pretty straight forward (although what are you really going to “unit test” on either?). I would imagine functional tests would be best for schemas/xslts.

    Orchestrations are really the big pain point for me as they seem like a place where things can really break :) I have been researching the possibility of hosting an orchestration in my own code. I could then fairly easily mock out the in/out ports and allow for a decent unit test … I am still researching this though. The big problem here would be in maintainance (its alot faster to just make a small schema change than to go through and then change the mocks as well).

    Overall I find biztalk to be a very intriguing product. I do however find a need for a “biztalk light” … while great for scalability, there is a pretty heavy sacrafice on per item speed for smaller systems.

    Also they REALLY need to get a good UI guy or twenty on the team :) the interface takes me back to VS.NET 1.0 and all the lovely intricacies you had to put to memory (like re-adding references so it sees changes, trying a restart of the environment if you have trouble, etc)

  8. Greg,

    I concurr with Jeff that testing biztalk solutions can be pretty hard, and yes, unit testing as we know it is pretty hard. However, there are certainly a few things one can do to improve it a little bit. The first thing is to clearly break up your solution so that you can test it:

    1- Schemas and pipelines: Normally many people don’t think about unit testing those, but they are sometimes one of the most problematic aspects, particularly if you’re dealing with complex flat files and stuff like that. I wrote a Pipeline Testing library that can really help to automate those aspects with the help of NUnit. I wrote it originally to test custom pipeline components, but discovered it works very nicely for the other stuff. See http://www.winterdom.com/weblog/2006/04/27/PipelineTestingLibraryPart1.aspx

    2- BRE: The Business Rules Engine is accessible via a .NET API, so you can use that to create tests for your business rules that way.

    3- Maps: Maps are rather inconvinient. There are ways to extract the XSLT that the compiler generates and you could use that for testing, but it’s rather awkward to be sure

    4- Orchestations: This is the big paint point, I guess, and not much you can do about it. You’ll want to avoid having too much code in your Expression shapes and moving that into .NET components you can test, so that helps some.

    Anyway, maybe this will get you some extra ideas for that.

  9. jlynch says:

    Greg,

    Welcome to the world of BizTalk development!

    I’ve been developing integration solutions with BizTalk Server since before it’s initial release seven years ago and you are correct, it does not allow for a very “agile” development methodology, nor for (formal) test driven development.

    BizTalk Server is basically a set of tools provided by Microsoft that generate XSD, XSLT and C# code as well as a runtime to process this code. Everything that BizTalk does “could” be written by hand and unit tested the same way you are used to. However, the time savings from using BizTalk is enormous and the code produced is excellent (you can set a registry entry to have BizTalk emit the C# code during a build).

    Think of BizTalk unit testing as a back box. It takes a known input and produces one or more expected outputs. Some parts (schemas and maps) of a BizTalk solution can be individually tested in Visual Studio but generally the entire application must be tested as a black box on the developer’s workstation or on a staging server. You can automate this application level testing using scripts and the BizTalk object model but I’ve found it more efficient to do this manually.

    It’s not a perfect solution but it certainly beats what was required before BizTalk. Like everything else (including Agile), it’s a trade-off between “control” and “speed of development”. In this case, I’ve choose speed!

    Feel free to ping me if you have any BizTalk questions.

    Jeff

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>