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

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.

Why you should write code and customizations like a boy scout

As the cost in time and effort of refactoring goes up, developers will add more bad code because it’s easier and quicker.  The result is the bad code in a project is like a snowball being rolled in snow, it just gets bigger and bigger – Hosk

I was reading an article which had the concept of the boy scout rule  boy scout rule, it’s from the pragmatic craftsman and I would recommend the excellent book  The Pragmatic Programmer

If you haven’t read it yet, I recommend you, it will help anyone who has to write any code or is doing any development.

Development and the boy scout rule

Boy scouts have a rule

Leave the campground cleaner than you found it.”

The other makes this point about code

“the code cleaner than we found it.”

What does this mean

The meaning of the quote with regards to code, is to encourage coders not to add bad code/quick fix code.

I would classify quick fix code as pushing and poking in some code to fix a problem, which adds to the complexity of the code rather than simplifies it.  It might fix the problem but if the code is poorly written and structured it is moving the code towards spaghetti code

If you think about a teenager who keeps putting off cleaning their room by hiding dirty clothes under pillows, shuffling things in cupboards.  If the teenager keeps doing this in the end the room turns into a big mess.  This is ok until the teenager wants to find something, they can’t because stuff is everywhere, there is no order and it’s hard to work out where to look.

Instead of cleaning and tidying up the room, developers when adding bug fixes, keep placing quick fix statements, which over time slowly creates bigger and bigger methods, code complexity increases.  The code because tightly coupled and starts to get more like spaghetti (e.g. code is linked together),  maintaining, enhancing and debugging the code becomes difficult.

This is where the boy scout rule should come into play

Leave the camp ground cleaner than you found it.”

If you adhere to the rule above it would mean instead of adding quick fix code, you add the code properly which may mean refactoring classes and methods and keeping the code.  It will probably take longer in the short term but it will keep the code well structured, simple and readable (why code readability is important)

Code which isn’t readable (the code which gets the quick fixes) is

  • Difficult to understand
  • Longer to debug
  • hard to maintain
  • tricky to extend

The codes growing method/class size, increased coupling and  added complexity results in the code taking more time and resources to maintain in the future.

When changing code you should focus on making it readable and adhering to good programming standards.

The benefits are

  • Removes duplicate code
  • Easy to understand
  • Consistent
  • Small methods which do one thing
  • Logically structured and designed

What I don’t like about the boy scout rule

The idea is great but when trying to explain this concept to other developers.  For developers/programmers to follow this rule it will result in them doing

  • Refactoring code
  • Writing better
  • Keeping to high standards
  • No quick bug fixes
  • Increased time and effort to change code
  • Increase in Testing

It’s the difference between quickly shoving some clothes in a draw and cleaning the whole room.  Interestingly outside of coding I am very messy person

Acting like a boy scout and follow their rules and tenants is not initially appealing to most developers, particularly if it’s going to take extra time and effort.

My point is it can be hard to persuade other developers to put this amount of effort in, even if they will benefit and save time in the long term.

How do we sell the long term benefit over a short term gain

Help your future self

What I try and do is explain to developers is this will save themselves time and effort in the future and will make their job a lot easier in the future.

If you wrote the code now, there is a good chance you will pulled back into bug fix, maintain and enhance it later on.  When you are working on a project full time, you have a great understanding of the project and you are in the project zone.

Being in the project zone means you understand the code AND all the business rules/business knowledge which goes with the project.  Like sportsman being in the zone doesn’t last and you move onto other projects (although sometimes it doesn’t seem like that).  Due to your extensive knowledge of the project, the business logic and the code you will be the prime candidate to fix any bugs which get raised.

The Messy Garden Shed

If you think of a project customizations like a garden shed.  If every time you use the lawn mower, spades, bird feed, kids toys you tidely place all the items back.  When you need to go into the garden shed a few weeks/months later you can easily find everything without having to remember where you last put things.

If you have a messy garden shed where everything is thrown into the shed and items are over and under each other.  To find the item you want you would have to try and remember what you used last (you might not have been the last user). If you can’t remember you can slowly start pulling things out, looking around.  With everything scattered around it’s difficult to know what’s in the shed, let alone where it might be.

It takes a lot longer to find things in the messy garden shed but if you went into the shed the day after you used the spade, you would have a good chance of knowing where you put it.

The messy garden needs you to remember where things are, this is similar to needing to understand the code and business logic in complex code solutions.

In six months plus time you won’t know the code and you definitely won’t remember the business rules and business logic.

So the code has to be as readable as possible and should not be complex

Scare them

You could try and scare the developers with this great quote

Why you can’t let standards drop

This is a great rule but I’m not sure how effective this would be at movitating people to tidy and refactor the code.  Unless you hired a violent psychopath to walk around the office once a month and maybe do a few code reviews.

Developers should have enough respect in their work to do this as a matter of course or to help themselves out if they have to fix the code later.

Remember

Go round the officing saying this to fellow developers at least once a day

Times may change but standards must remain

Enjoy your work and take pride in creating excellent simple code because as soon as you stop doing it, so will everyone else