Geeks With Blogs
Charlie Mott


Roy Osherove on his blog and in his book gives guidance on the naming of unit test methods. For use with BizUnit end-to-end integration tests, I have extended these recommendations below. Implementing these conventions has the following benefits:

  • Makes it easily to understand the purpose of the test.
  • Make it easier to find specific tests.
  • Gives a visual feel for integration use case test coverage.

Hub-and-Spoke Solutions

For hub-and-spoke solutions, an integration use case can typically be identified by the source system and the message type.  As such, the following pattern is recommended.

Format:   SourceSystem_MessageType_MessageScenarioProperties_ExpectedBehaviour()

Sample:   Maximo_Invoice_Valid_Success()
Sample:   Maximo_Invoice_InvalidStructure_ValidationExceptionHandled()

Integration use cases that implement a convoy pattern may need a slightly different structure. There may be different source systems and\or different message types.  If the source system is different, replace with the orchestration name.  If the message types are different, exclude message type details.

Format:   ConvoyOrchestrationName_Scenario_ExpectedBehaviour()

Sample:   JournalConvoy_Valid_Success()
Sample:   JournalConvoy_SingleValidHeaderMessage_TimeoutExceptionHandled()

ESB Toolkit Solutions

In ESB Toolkit solutions, an integration use case can typically be identified by the rules that are used to select which itinerary to use. A rule might evaluate: an xpath value (message type, status value, message type version); receive location (WCF, File); etc.

This variety makes it more difficult to enforce consistency in test names. As such, the following is recommended. The test method names are prefixed with the message type for the same reasons as above. Rules are delimited by  "And". The rule list excludes the prefixed source system and message type. Try to be consistent in the ordering of the rules. e.g. (1) Version (2) Status.

Format:    MessageType_Action_OnRampLocationType_MessageStatus_ExpectedBehaviour

Sample:   Customer_Create_WsHttp_Valid_Success()

Remember, you can write more fine-grained BizUnit tests for the BRE itinerary selection rules without re-testing the whole itinerary. See the Business Rule Engine BizUnit Test Steps codeplex project for guidance here.  Also see Mike Stepheson's blog article on XPath query testing.

Code Analysis

I realise that the above recommended conventions breech the Microsoft Code Analysis Naming rule "CA1707: Identifiers should not contain underscores". However, I feel it is worth disabling this rule for test projects to gain the benefits described above.

Posted on Monday, July 5, 2010 6:45 AM BizTalk , BizUnit , ESB Toolkit | Back to top

Comments on this post: Naming Standards for BizUnit Integration Tests

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © charlie.mott | Powered by: