Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
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.
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.
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
Unit tests and CRM in my experience have never really happened for a number of reasons/excuses, I have listed them below
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
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.
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
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.
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
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.
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
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.
Business Applications communities