BizUnit Extensions and Tools Roadmap
This page lists some of the things that are forthcoming and our ideas on where the tool can go in future.
Libraries and Extensions
Libraries
- WSE -- (Mike Stephenson has done this and will be incorporated with permission soon)
- WCF -- (same as above)
- WF -- (waiting for WF v4 to find out whether this is really necessary)
- SSIS
- SB (Service Broker)
Links to other community tools
- OrchProfiler : Enables us to do more “white box” testing. (i.e.) check that some steps were executed, check if the performance level is good (if the time taken to execute the step was less or more than a particular threshold.
- Quick Counters : Useful for perf testing
- Pipeline Testing Library : work underway. Will be available in 3.0 beta-2
Support Tools
- XSD
- CodeSnippets - on the way - will be available in Beta-2
- Generate BizUnit test script (available in BSF)
- Test Guidance Packages (available in BSF)
- TreeView GUI / WPF GUI
- WF 'TestScript GUI'
- Custom DSL
- Repository
Context
BizUnit (with the Extensions project) is definitely a useful tool. However it is currently very developer intensive and one of the aims in the roadmap outlined below is to make it much more “tester friendly”. Any tester using this would still have to be fairly technical and understand the message flow through the system and how the various artifacts fit together, but hand-crafting raw XML is error prone and this limits the appeal of the tool. Many developers have taken BizUnit and extended it in various ways to suit their needs and this will always be something we support and want to see more of. We are also aware that not all those contributions are in the public domain for IP reasons, which is understandable, but we do hope that there will be more public;ly available extensions and tools (not just those written or originating here)
Some of the ways the tool can be extended are described below.
- GUI: Provision of useful GUIs.
- Abstraction of test case source/format via a Provider pattern*
- Abstraction of test cases via DSLs
- CodeGen: Auto-generate test cases
- Software Factories: , guidance for testing specific types of projects etc
As indicated above, there are some more contributions forthcoming but we cannot promise any dates. But if you find the roadmap interesting and you can contribute, we would welcome your participation.
The roadmap in a sort of rough order is presented below.
1.
GUI: Provide a win-forms config file editor. With a tree-view of steps, people can add as many steps as they want and configure them instead of raw xml coding. Consider using the Windows Workflow Foundation to design complex test scripts that have workflow, branch conditions etc. It also makes for a nice jazzy GUI.
2.
Abstraction of test format: Introducing some abstraction on the persistence model so that the test runner doesnt care about the XML. The 3.0 engine allows injecting streams and strong typed test cases so maybe there is some scope to put in some layer in the middle then developers can write their own components to persist to excel, db etc. This could even link into a SQL repository of test cases.
3.
Abstraction of test cases: In an early project, while tracking the path of messages we found that we were very often testing the same artefacts (common queues, databases, logging areas etc) and if we had to change some properties such as timeouts or file patterns, then we had to go and change numerous files. We solved this to some extent by writing a generic system where each test case addressed one entity (such as a queue or a db table) and then lined up multiple test xml files for each scenario and could reuse these files across scenarios. Arguably, this was our own Domain Specific Language. It would be interesting to see if we can make DSLs a first class part of BizUnit. It would be nice to have a sort of ‘repository’ of common steps which we can label with some aliases and then use them. In the editor they would be read-only and can only be changed in the core “domain step repository”. The system can then pick up the actual step from the repository and run the collection of steps as it would normally. The repository could even be written in SQL Express and have some management tools.
4.
Code Gen : Generate BizUnit Scripts for a given assembly or application. Basically this would parse the application object model and write a test case for each orchestration. It would look for the sequence of receive and send ports and write steps for each. Of course, file based ports are much easier than HTTP or SOAP ports. If the developers have some instrumentation on complex ports then we can run some checks using WMI. This has been done to some extent in the BizTalk Software Factory.
5.
Testing Software Factory: This would be a sort of amalgamation of all the rich GUI interfaces, add-ins via GAT, test case templates, snippets, reverse engineering applications to generate test scripts and so on along with all the necessary guidance. There would however have to be more consensus on the way testing is structured and carried out and the kind of test patterns we all follow to make the factory really useful. Again, this can be implemented as a Guidance Package for the BizTalk Software Factory.