BizUnit 4.0–Released

I’ve now released BizUnit 4.0, it includes a couple of minor bug fixes found in the Beta release, including a fix to the way the concurrent steps are executed.


~ by kevinsmi on May 22, 2011.

10 Responses to “BizUnit 4.0–Released”

  1. Hi Kevin thanks for your ongoing effort. Have you got a post about the main features which are different from previous versions?

  2. Hi,
    Take a look at the BizUnit 4.0 Overview post: also, there is a getting started guide in the MSI which should help. The big change is the serialisation format is now XAML, this means that tests can now be ‘coded’ i.e. built by driving the object model or declarative by authoring XAML. Test cases can be round tripped between coded and XAML, this approach makes it significantly easier to build test cases. There are a bunch of other changes which have a big impact also such as the ability to import test cases.

  3. Hello Kevin,

    The framework looks very impressive. Maybe this question is obvious, but I am puzzled how I could implement long-running tests. For example, the my test scenario would
    1) send a message to a web service in fire-and-forget style.
    2) The message initiates a long running transaction, just like in your SDK blog post example ( The transaction might even involve human approval, who might be on holiday 🙂
    During the transaction the test process should just relax and wait.
    3) When the transaction is completed (minutes, hours, days), the test process should be notified. Is there way that the test itself implements a web service allowing being called with the results? And until not being called, it just waits?



    • Hi George,

      Firstly, a good automated test should be fast to execute, for a typical ‘enterprise’ type project, I would expect to be able to run an entire test pack consisting of hundreds of test cases in less than a couple of hours. Even a test case that took minutes to complete would be classed as ‘long’ yet alone hours or days. If you have manual steps in your test scenario, they should be removed and automated to ‘simulate’ what the user would have done, this way you can also simulate the user taking different actions. Automated tests need to be fast to execute and predictable – meaning that you should get the same result every time it runs (assuming there are no bugs in the code base that you are testing of course), if there is a ‘physical user’ involved you cannot ‘guarentee’ what they will do, but you can with an automated test step.

      That aside, to answer your question, it sounds like you require BizTalk to call back into your test case to say ‘transaction complete’, to acheive this, you could have your test case exposing a Web Service end point. To do that you would need to write a custom BizUnit ‘test step’ to expose a WCF endpoint that BizUnit could call into, this is certainly doable though there is not one provided out of the box, WCF makes it relatively straight forward too. However, it’s not clear to me what the web service end point is in reality, presumably you must have a system that BizTalk calls back into? which may or may not be a lot of work mocking it out as a test step or it may not be appropriate to mock it out as a test step. Personally I would probably take a slightly different approach in terms of determining whether the ‘transaction was completed’, for example, if your solution uses BAM to log/track the transactions progress as most of the solutions I design / work on do, you could use a database test step to wait for the BAM record to be correctly written, this step could be configured to wait for a given period of time. But again I would not recomend it to wait indefinitely, many of the test steps have defined ‘wait periods’, this is to handle the scenario where an action never happens, or takes too long, if this is the case the test case should fail and the next one run, again test cases should be executed in a timely manner.

      I hope that makes sense and is of use.

      • Hello Kevin,

        Thanx for the extensive answer. Concerning your theology on automated testing, I can except your reasoning completely. I hope I can avoid excommunication 🙂

        My point is not really about the “longrunningness” but the ability to wait for notification by web service. As I understood your answer, it is not out of the box but should not be a problem. We have enterprise service bus (ESB) scenario. Our data providers expose their content to the ESB via regular SOAP web services that are being polled. On the consumer side, the ESB pushes the detected changes to the client systems implementing WS Notification standard. We want to test our ESB solution, simulating both provider and consumer side. Hence waiting to get notified is crucial. Since ESB also will provide filtering capability, certain provider input should never reach the clients. Therefore the test succeeds if no response arrives.

        Thanx again,


      • Hi George,

        No problem. Writing a new test step is very straight forward, so thats definitely a route you could go down – I’m pretty sure I did a post on how to write one, but I’m currently overseas on business and having ‘slow internet’ fun and can’t seem to get back to my previous posts right now. As long as your test cases are fully automated, they run in a timely manner, and have predicatable and consistent behaviour you’ll be able to configure the expected behaviour for each test case whether they expect a response or not. Best of luck

  4. Hi Kevin,

    I have installed the BizUnit. Does the installer do anything besides copying files to the destination folder (like writing to the registry, putting dll-s to GAC)?
    I would like to avoid the demand of installation of BizUnit for our developer team. The preferred way of work is just check out our solution from the source repository and go. Is there anything the installer does and I should be watch out for?

    Thanx in advance,


    • Hi George,
      No, the installer just lays out the binaries, src and documentation on disc. For most projects we tend to include the BizUnit binaries in a ‘libs’ or ‘referencedassemblies’ directory in the src tree for the solution and the test code simply references the binaries. You should of course treat the source code of your tests in the same way as the src code of your solution, i.e. it should be checked into your source code repository, built using your automated build, and then of course your build should run those tests against your deployed solution. There is no need to build the BizUnit src code, though I typically keep the src code for any open source I’m using in my source code repository just in case the author pulls the src coude from the public domain, it does occasionally happen.
      I hope that answers your questions,

  5. Hello Kevin,

    It is not clear to me, how can I use the the XAML version of tests together with e.g., Visual Studio testing tool. I load the XAML files during runtime (btw. TestCase.LoadXaml method throws NotImplementedException, fixing costs only a single line of code), but Visual Studio demands me to have the test methods strongly typed and compiled in. How can I make NUnit or VS2010 dynamically discover my XAML tests in a regular folder without recompiling any assembly?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: