Tag Archive 'Test-Driven-Development'

The integration testing is concerned with testing customisations within the context of CRM to ensure that the various components work together correctly. In my current work this is mostly related to custom plugins in CRM and custom integration with SharePoint. The key point is that with this type of testing I am not concerned with the user interface, rather the underlying processes.

In many ways the integration tests are very similar to the unit tests, they are code based test created using the Gallio/MbUnit framework. However, instead of testing code in isolation and mocking dependencies, the integration tests test whole systems. This is achieved by making create, update, delete, etc. calls to the web service to simulate user actions.

Test setup and tear down code can become length as you need to be able to setup scenarios to be able to test, including creating test records and enabling/disabling plugin to allow actions to be performed that may otherwise be blocked.

It is also during integration testing that I introduce testing as specific users to test security related constraints. This is easily achieved in CRM as connections to the Organization Service support impersonation.

Integration tests are also good where a user has identified an issue with a plugin in a scenario you hadn’t thought of before. I tend to use this as a trigger to create new integration test to match that case, and then one or two more boundary cases around it.

As these tests require connection and interaction with CRM, they can be slow to run. As a result, I tend to run these in TeamCity, where they can be left to run on their own, or I will run specific tests in order to help track down an issue. Whilst setting them up may seem to take a long time, relative to “productive development” time, they soon become invaluable for regression testing as new functionality is developed or existing code is refactored to improve performance, etc.

In this example you can see that the test is disabling a plugin, setting up some test address records, re-enabling the plugin and then executing the test. After the test is complete it cleans up the test records.

Ideally the code being tested should not rely on external resources, where such dependencies exist they should be mocked to isolate the code being tested form the external system. In the case of plugins, this means that testing units of code should not require the code to have a connection to an actual instance of CRM.

CRM2011 has improved the way that plugins are developed against CRM, especially with the introduction of the CrmSvcUtil.exe tool for creating early bound classes for entities in CRM that can be used alongside the CRM SDK assemblies. Additionally Microsoft has provided interfaces for accessing CRM and data provided by CRM to the plugin:

IOrganizationService

IPluginExecutionContext

ITracingService

This means it is simple to mock the CRM services to test the plugin in isolation.

However, mocking a whole execution context would be a bit of a lengthy exercise, especially the IPluginExectionContext object is different depending on what messages and what pipeline stages you are writing the plugin for.

Thankfully there is a project on Codeplex that makes this job simple: CrmPluginTestingTools. There are two parts to this tool:

A plugin that you register in CRM as you will register your final plugin (including configuring pre- and post-images) that serialises the plugin execution context to xml files.

A library of classes for de-serialising the xml files into objects that match the IPluginExecutionContext interface.

Once you’ve registered their plugin, perform the steps that you plugin will handle; grab the output xml files; head into Visual Studio and start crafting your unit tests.

I tend to use the de-serialized xml files in my unit tests as a starting point and then use the object model to update the IPluginExecutionContext objects to structure the data for the specific test.

The execution context is only half of the story, I also use Moq to create a mock IOrganizationService that code being tested will be given instead of an actually connection to CRM. By doing this I am able to isolate the code from the CRM server plus I can determine what will be returned without having to setup records in CRM. I can even mock any type of exception if I want to test that aspect of my code.

As with all my automated tests, the unit tests are built on top of Gallio/MbUnit testing framework. This means that I don’t need to think about how to run the tests, I know they will all work with TestDriven.net in Visual Studio, the Gallio Test Runner – for a more graphical UI on my workstation, and TeamCity continuous integration server.

Overall Process

Of course, the plugins I write and single-class monsters, instead I break up the code in logical units (classes/methods) of responsibility and I test each unit on its own. If a unit of functionality doesn’t require access to CRM or the plugin execution context then I don’t worry about mocking those for that specific test.

Solution Structure

This solution contains several projects, these being:

Crm2011.Common

This contains the early-bound classes generate by CrmSvcUtil.exe which are used by several solutions.

Crm2011.Plugins.Address

The plugin that is being written/tested.

Crm2011.Plugins.DeploymentPackage

The project for deploying the plugin into CRM. The steps and images registered in this project should match how the CrmPluginTestingTools plugin was registered.

Plugin.Unit.Tests

This contains the unit tests created for testing the plugin, as well as the serialized execution contexts used by the unit tests. This project also contains a .gallio file that is the project used to run the tests in Gallio; and a .msbuild file that is the MsBuild project used to compile and run the tests in TeamCity.

SerializePluginContext & TestPlugin

The CrmPluginTestingTools projects for de-serializing the xml execution contexts in the unit tests.

The above code is a single test fixture (class that contains unit tests); a SetUp method that is run before each test; and a single unit test. I have added Metadata attribute to the test method so the setup method can determine which execution context xml files should be de-serialized for the test. The first two lines of the test setup and execute the plugin, the rest of the test ensures that the ShareVariables on the execution context have been correctly set of the given data.

The following example indicates how the organization service can be mocked to ensure that the plugin is making the correct call to CRM:

By using unit testing in isolation of CRM, it is possible to create the vast majority of a plugin without having to touch the CRM server itself (with the exception of creating the test serialized execution contexts). Not only that, once you have created the unit tests, it is possible to run them again and again without having to manually click through CRM, so if you make changes to entities in CRM you can easily re-run the CrmSvcUtil.exe to update your early-bound classes and then run the unit tests to verify that they still pass.

To mark my return to blogging, I’ve decided to write a series of blog posts around automated testing in CRM2011. This is part 1, an overview of the types of tests I’m creating and the tools I’m using for creating and running the tests. Future posts will look at each of the types of tests in turn and look at how I’m using TeamCity to automate these tests.

The automated testing in place for CRM2011 is broken downv into the following three types of tests:

Unit Tests

These are small, fast tests that are written in code and are designed to test isolated pieces of code.

Integration Tests

The tests are for complete systems or sub-systems, e.g. a plugin running in the context of CRM. However, they are still code based and tested in without User Interface interaction.

User Interaction Tests

This is tests of the system from the perspective of the user. They are based on a simulation of the user clicking and entering values in the browser.

Testing Components

The basic components that are being used for automated testing of CRM are as follows:

This is an automated continuous integration system that is used to both compile the source code and run unit tests. It has also been configured to create a backup of the customisation solution from CRM into Subversion.

Tool Stack

The following diagram illustrates the tool stack used for each of the types of tests, with the system under test at the top of the stack and the host environment at the bottom:

All of the test can be run in either Visual Studio or TeamCity and all of the test are based on the Gallio/MbUnit test framework. In addition, the unit tests uyse Moq and CrmPluginTestingTools to allow the unit tests to run in isolation; the integration tests simply call straight to the CRM Web Services for both setting up the test and confirming the results; the user interaction tests use WatiN to control IE to run the test.

Recently I’ve had reason to take an code library written in C++ and port it to C#. Whilst I dabbled in C++ on a compilers course at university, I hated it then and I still hate it now. I personally think it’s an abomination and should be consigned to the great garbage collector in the sky. Whilst I can just about read the C++ syntax there is a lot that I don’t understand about it.

The library I was porting had semi reasonable documentation outlining what classes exist and their methods and a brief description of the overall usage. This gave me a good starting point, however the documentation didn’t include example usages and expected results, for this I was forced to delve into the code.

One development paradigm I have been interested in but have been unable to find a decent project to test it on is Test-Driven-Development and this seemed like the perfect project to try it on. So I set to work on the first iteration getting the test set up. Without knowing exactly what results I should be expecting I was finding it hard going, so once again I dived back into the old code.

Thankfully, the developers of the C++ library had create a fairly comprehensive set of unit tests and with my limited C++ knowledge and a text editor with RegEx Find & Replace I was quickly able to convert their unit tests into NUnit based unit tests.

Now, with a full set of unit tests at my disposal I was quickly able to bash away at the library and very quickly got working code without the need to trawl through ghastly C++ code.

Hooray for Test-Driven-Development and three cheers for Test-Driven-Porting.

ps. The library I’m porting is an open source library for Bell Ringing – yes I know I’m a geek but anyone that has followed everything else in this post must also be a geek ;-). Once I’m finished I will be releasing my code under an open source license as well, I just need to pick the right one.

pps. I may have exaggerated my hate of C++ a little. I believe all languages have their place, even the esoteric languages like LOLCode.