If you have attended the increasingly popular CRM Saturday conference, you probably gained some valuable insights around the key aspects of delivering successful CRM implementations, and how to overcome the main challenges one may face during the implementation.
If not, I encourage you to visit the web site, it has great speakers, great content, and lots of networking opportunities… not to mention is one of the few Dynamics events out there where attendance is 100% free.
Two of the sessions were around test automation and how to implement a true DevOps strategy for Dynamics CRM, two key areas and best practices to increase the overall quality and healthiness of your CRM implementation, which, in turn, would give you the following benefits:
- Turning your customers into even more happy customers (external)
- Making your colleagues a bit less stressed because of regression / production bugs will be reduced (internal)
If you are still not convinced about why your team should unit test your code, here’s another blog post with the slides of the test automation presentation.
Once your team realises how important unit testing is, the next immediate question probably is:
-
“Ok, I have an implementation which has been running for years , and I have a bunch of existing code, not tested. At the same time, I have a limited set of resources and trying to unit test everything would be mad… where do I start?”
Ideally, one should achieve a code coverage above 90%, but if you have limited resources, my advice would be: the 80/20 rule.
Try to find the 20% of your code which represents at least the 80% of the total number of executions or executed time, just because if there is a bug in there, then it is likely to affect more users than a piece of code which is executed from time to time only (this might be actually more complex as maybe something than just runs from time to time may have a bigger impact based on a million different variables… but I hope you get the idea).
The next question might be…. how to measure it?
Well, it turns out, from a plugin / codeactivity perspective, you could extract that information from the System Jobs entity rather easily.
Every time a plugin / workflow is executed, a new entry in that table is created, with the Created On, Completed On, fields etc, so you could actually measure how much time a single workflow / plugin execution took. If you have an On-Premise installation, then that is just a SQL query with some groupings, if On-Line, then a data extract plus some Excel manipulation magic should be enough too or… make use of the great Organisation Insights feature in AppSource:
Are you unit testing your code? If so, how did you start unit testing legacy code? Did you use a different approach? We would love to know more about your own experiences.
Please leave a comment below.