Experiences of Unit testing with Microsoft Dynamics CRM Projects

Many moons ago when I was a Java developer and learning how to code, I remember two things which had a big impact on my coding.  One was learning about Design patterns and the other was learning about Test Driven Development.

Writing unit tests for your code before you actually write the code seems like a strange thing to do and I didn’t meet many developers who did this or in fact bother writing unit test at all.

I found writing code which you knew was going to be tested with units tests forced me to write modular/reusable code.  It makes you write code which can be tested and usually this means each function does only one thing (because that’s easier to test).

The code is more likely to Single responsibility principle and each class and method doing one thing, the reason for this is because it’s easier to test something which only does one thing.

Pro and Con’s of Unit Testing

When unit tests and writing unit tests are mentioned this question is not usually far behind

What’s the benefit of writing extra code to test your code?

This can be a hard sell to some developers, it would be similar to trying to explain to a messy teenager the benefits of cleaning your room.   One the major complaints raised against writing tests is it takes extra time and we developers don’t have time to do it.

Writing unit tests involves thought and effort creating dummy data, deciding where to mock or stub to get enough data to test the code.  This can feel like a lot of wasted time when you can spend half a day getting the data created to test your code.

This effort can be too much for some developers and they will never like writing units and always view it as a waste of time.  This point of view is a common initial thought until the developer tries it and starts to see the benefits with the improved confidence of their code.

The irony of the aversion to unit testing is developers test their code by creating console apps or debugging the code. Unit testing is taking this process and making it reusable and self-contained

When writing unit test you stop and think about how the code and objects are going to be used.

Below is my experiences of unit testing and CRM, there are probably lots of companies and CRM developers are are unit testing their code

PRO’s of Unit Testing

• confident the code works because it has been tested
• Higher quality code (more modularised/reusable) to enable tests to be written
• Any changes to the code can be tested quickly with no extra effort once tests have been written
• unit tests can help developers new to a project understand how the code (should) work
• very useful for testing refactored or bugfixed code
• It’s easier to debug unit tests than deployed CRM code

CON’s of  Unit Testing

• It takes extra time to write the unit tests and prepare the data
• Unit tests have to be maintained and updated
• You have to learn the testing framework and how to write tests (this is non-revenue generating time)
• A feeling of not moving forward

My Experience of CRM Unit Testing

Unit tests and CRM in my experience have never really happened for a number of reasons/excuses, I have listed them below

Smaller projects

Smaller projects usually remove all non development tasks and reduce everything to the bar bones.  Unit tests were seen as non productive time the customer didn’t want to pay for.

Often small projects had a very limited about of code customizations

Time

Developers never have enough time to do everything the customer wants and usually the first thing to get snipped out is testing and unit tests.  See Why rushed projects/code doesn’t save time and reduces quality

Best Practise/Best Testing framework

Most CRM projects I have worked on haven’t used unit testing.  below I detail some of the reasons this (I’m not saying I agree with them but stating them).  I would say I wasn’t always keen to unit test my code but part of the reason was because the code in the projects wasn’t unit tested.

Cost

Some unit test frameworks do have a cost associated with them.  Microsoft Fakes used to only be included in the Ultimate version of Visual studio (which was very expensive) but it got voted into visual studio premium on Jan 30th 2013.

CRM developers didn’t seem to know (or maybe care) about this because I didn’t meet any CRM developers who liked or did any unit testing of the plugins/custom workflows until recently when I joined my current company.

Joining a project with no unit tests

The decision to unit test usually happens at the start of the project.  Many of the projects I have worked on didn’t have unit tests.

Legacy code impossible to test

Most people don’t bother to try and write unit tests for legacy code.  I can understand this because it would be very difficult

Plugin/Custom workflows hard to test

What do I mean hard to test?  Plugins/custom workflows need a IPluginExecutionContext context so you can test the plugins.  So to properly test a plugin you would need to create a IPluginExecutionContext with the correct attributes.

This would take quite a bit of effort.  To get an idea of all the data created you can use the debugging with the plugin profiler as an example.  When you debug with plugin registration tool, you set it to record the data for a certain plugin, run through triggering it in CRM.  This will create an xml file with all the fields and values.

You can then use this file to recreate the scenario you ran through in CRM and it will pass all those field choices into your Visual studio debugger.   This blog runs through the process

No insistence of unit tests

The projects I worked on, no one insisted unit tests were created, apart from one project.   Instead the code would be tested by each developer and then put forward to an integration test.

Unit testing has to be a company or project policy or something which developers of a company are doing.

Senior developers weren’t doing it

Junior developers learn good and bad habits from senior developers.  In most of the projects I have worked on there were no unit tests.  I haven’t met any (1 or 2) CRM developers who write unit tests and most do not promote unit testing.

Examples to copy

When you type CRM and unit tests you do not get many results back and this suggests unit testing CRM code is not common practise.  More examples and blog posts would make it easier for CRM developers to use this code in their projects.

How Hosk tested his Code

The way I developed my code customizations was to create the code in separate class outside of the plugin code.  I would then create a console app and test the code by passing in a IOrganisationservice, TracingService and Entity.  This allowed me to walk through the code and retrieve data from the development CRM organisation.

I’m not entirely sure how other developers would test their code, I have a sneaky suspicion most would use integration testing (deploy and test it using CRM) and look at the log files.

This article was in draft status for quite a while and in the mean time I have started writing unit tests. I first tried using RhinoMocks and then found Microsoft fakes was free in the premium edition.

I have written the article

Why CRM Developers should unit test their code

I am now a firm believer CRM developers should be writing units for their customizations and there isn’t any excuses why unit tests are not written.  The lack of unit tests is not limited to CRM Development but wide spread in a lot of programming.

There are some difficulties in writing unit tests in CRM but it is achievable using Microsoft fakes.

CRM Project with Tests

There has been a drive to test the code in a project and the developers are writing tests for code which already exists.

I won’t lie this is a tricky a task.  When code hasn’t been written with testing in mind it can be very difficult to test.

I will say some tests are definitely better than no tests and the code was decently structured so a lot of the code plugins are using is now separately tested.

It has taken some time for developers to get to grips with the testing framework and the testing methodology.  Testing is a different mindset and it takes  bit of time to learn the tips and tricks and common testing methods.

The benefits have been

• Tests any developer can run
• The business logic is quite complex in the project, so having a method to step through parts of the code is very useful.
• Tests can be run be developers who didn’t create the code, much quicker than trying to test the code yourself.
• Easier to see if your code has broken other parts of system

Plugins and testing

Some developers can have a blinkered view of testing the plugins themselves.  Plugins are not always easy to test and sometimes a plugin doesn’t do much.

A create plugin might validate values

A plugin could update related records

I personally remove all the code from the plugin and create separate classes where the constructors take IOrganisationService and TracingService.  The method can then take an entity record which has triggered the plugin.

Unit tests can be run against the code which is split up into small focused classes/methods.

At the end you plug all the small tested parts together and link it to the plugin.

Why have I changed my mind about unit tests and CRM

 

Looking at the list of reasons why unit testing was done on the CRM projects I worked, I can see they are not reasons they are excuses.   Most disappointingly is some of the excuses for not writing unit code are excuses I have been making to myself.

I have been reading  Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) and Uncle Bob mentions we as developers/programmers should be testing our code and our code should be good.

He has this quote in Clean Code

Why does good code rot so quickly into bad code? We have lots of explanations for it. We complain that the requirements changed in ways that thwart the original design. We bemoan the schedules that were too tight to do things right. We blather about stupid managers and intolerant customers and useless marketing types and telephone sanitizers. But the fault, dear Dilbert, is not in our stars, but in ourselves. We are unprofessional.

This year I have been thinking about the quality of CRM code/customizations and have been coming to the conclusion the quality of code in CRM projects need to be better.

I re read my post –  The Frustrations of a CRM Developer many of the frustrations come from poor code.

Quite a few of the CRM Developers articles I have written this year are focused on creating quality customizations

• Bad code is like a virus, don’t get infected
• Why rushed projects/code doesn’t save time and reduces quality
• The problems with complex code and complex CRM Customizations
• Why Code Readability is important
• What’s slowing down your CRM development?

Before reading Clean code I knew I should be writing unit tests but took the easy option of not doing it.  After writing some unit tests for my current development, it has been so much easier refactoring my code and making changes.  Having 40 unit tests testing code change gives me confidence the refactored code works.

Unit testing helps projects from falling into a state of Legacy code because writing code you can tests makes the developer

• Think about the code design
• Think about what the functionality should do
• Test the code more thoroughly
• Creates reusable tests to all developers on the project

I hope this and future blog posts will get more CRM developers to start unit testing their code.

The biggest driver for unit testing code should come from the developer, who has pride in their work and wants to deliver high quality code.  This is an attitude, it’s a desire to create quality code.

The benefits of unit testing are undeniable and if you start unit testing your work you will soon enjoy the benefits.  If you are already writing unit tests then keep up the good work and write a blog about it to encourage other CRM developers.