Unit tests are a vital part of emerging code design


Don’t limit yourself. Many people limit themselves to what they think they can do. You can go as far as your mind lets you. What you believe, remember, you can achieve.

Mary Kay Ash

When a developer writes code there is always an aspect of design to it.  Some developers spend more time on initial upfront design others like to start coding straight away.    The design and structure of code will emerge to a more efficient structure during the writing of the code, this process can be helped by writing units to assist the refactoring process.

Designing Code

I like to encourage developers to pause and think about the design of their code before they start writing code.  The benefits from developers thinking before coding

Think before you act

It’s quicker to change a design plan than design and code

This reminds me of the carpenter saying

measure twice and cut once

Thinking = planning

They are stopping to think about the task and creating a design is similar to looking at a map before you set off driving towards a destination.

  • A brief design gives you a plan
  • code designs emerge

You initial design will not be the finished design because designs are high level.  When you focus on individual parts of the design more questions and problems will come into view.

It’s like viewing something from far away, you see some general shapes and details.  The closer you get the more detail you see.

The role of unit testing in code design

Many people believe unit tests are written to catch bugs, it’s true writing unit tests could find some additional bugs you might have missed.

reusable tests for all developers.

It’s true unit testing has many benefits but here are the benefits to code design

Benefits of unit tests to code

  • Refactoring
  • Simpler code design
  • Code Documentation


the main benefit I have experienced with unit tests recently is the ability to refactor my code and run tests against the code to make sure it still works and hasn’t broken anything.

Simpler code design

When code is written to be tested the code design is simplified so testing the code is easier.  It’s easier to test code which does one thing and adhere’s to the single responsibility principle.

Code Documentation

Unit tests provide a working documentation of code.  Allowing other developers to easy see what the code should do by the tests and run/debug the code using the unit tests

This article (which is very good) THE ACTUAL COST OF TESTS – PART I, adds  additional benefits to unit testing

  • Code coverage
  • bugs in tests

The goal of code (design)

The way most developers work is they aim to get the initial code working and aim to tidy the code later.

This approach is driven by two factors

  • working code not matter how ugly can be shipped
  • The developer has proven their logic is sound

Primary requirements of code

  1. The primary requirement of code is deliver the functionality required

long term requirements of code

  1. Readable (expressive names, logically structured)(
  2. Modular/independent code to manage the effects of change (cohesive code, loose coupling)
  3. Reuse
  4. Easy to maintain/debug/enhance the code

The primary and short term goal of code can be achieved with minimal effort in the design of the code.  The code will deliver the required functionality but usually in spaghetti code with these characteristics

  • Big classes and Methods
  • classes\methods doing many things
  • high complexity
  • tight coupling

The above code is what I call Legacy code and developers have given up trying to keep this code manageable because the task of refactoring the project has become to big to contemplate.

An important aspect of refactoring is removing duplicate code, Martin Fowler has a great article on repetition.  Removing duplicate code has numerous benefits such as

  • Create reusable classes/methods
  • Reduces code
  • Better designed code

Unit Tests and refactoring

If you code has unit tests it allows developers to refactor the code with confidence because they can easily test the code still works by running the unit tests.

Unit tests fit in with the way developers write code (get it working first) but without unit tests the refactoring and structuring the code for the long term is  considerable more difficult because the developer would need to manually test the code is working.

Code designs emerge during the coding process, developers see more efficient ways to structure code which usually involves removing duplicate code, writing smaller more efficient code.

Code design can be viewed in similar way to writing a novel.  Novels go through many drafts and revisions whilst the writer removes unneeded sections and poorly written sections.  Some novelists can change the core structure/characters of books during revisions as a byproduct of investing more time focused on the task.

Code design is a similar process because it’s easier to restructure a working code design and improve a current design than it is to create a perfect code design first time.

Problems and efficiencies of code only come into view when a developer moves closer to the problem.

The key points

Without unit tests developers won’t refactor code to deliver the long terms benefits of well designed code.

Code and projects where code is not refactored reach legacy code status very quickly.  The developers who have to manage and work legacy code will take longer and longer to interact with the code (debug/enhance/extend/understand).

The end result is not writing unit tests will cost you more time and developers jobs are less enjoyable


Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM 2013

This blog will highlight useful information for any CRM developers wanting to learn about Microsoft fakes and Microsoft Fakes with CRM.

I have recently decided I should be unit testing my CRM code, to be honest I knew I should have been doing it before but I had excuses not to

  • The projects I had worked on didn’t have unit tests
  • The other developers were not unit testing their code
  • The company/project didn’t stipulate unit tests should be written
  • Unit testing CRM code is difficult

You can read about this in more detail

Experiences of Unit testing with Microsoft Dynamics CRM Projects

If you want more reasons why CRM developers should write unit tests then read this article it has 18 reasons benefits of unit testing your code

Why CRM Developers should unit test their code

Since I have started unit testing my CRM code not only is my code designed better (smaller classes/methods which are easier to test).  My code is tested and I have caught more bugs, particularly bugs where the testing diverted from the happy path and tested the alternative and exception path tests – Don’t just test the happy path.

The biggest benefit to having unit tests is you can refactor and change the code with confidence because after you have finished making changes you can test your code with unit tests.

What Framework should I use?

I wasn’t sure what framework I should use to test my code.  I had previously worked on a project where they used NUnit, another project used RhinoMocks.

I started writing some unit tests with RhinoMocks but found difficulties when trying to test some code using Metadata because the Metadata was a read only collection.  Microsoft Fakes is an isolation framework which allows you to create shims to overwrite read only data.

CRM 2015 – Understanding CRM Metadata

I had problems setting Attributes collection on the Metadata record.  This was a mixture of me not knowing standard unit testing methods and Attributes is a read only collection.

Many developers were put off using fakes due to cost.  Fakes was free in Visual Studio Ultimate (which is expensive).  The prohibitive cost put off many developers who turned to other free/cheaper testing frameworks.

Sometime in 2013 Microsoft bundled in Microsoft Fakes with Premium license (which is much more common).

Microsoft Fakes is included in Visual Ultimate and Premium in release 2012 and 2013, the key point is Fakes is free with Visual Studio Premium edition.

I had heard good things about Microsoft Fakes, it had shims which would allow me to overwrite read only collections.  So I decided to start testing with Microsoft Fakes.

Start learning about Microsoft Fakes

When I started writing a unit test, I quickly released I was going to have to do some fast learning.  The terms used by Microsoft Fakes were completely alien to me

  • Shims
  • Stubs
  • and no mention of the word Mock
  • Isolation Framework

There are two main hurdles when learning about Microsoft fakes

  • The terminology
  • Getting into the testing mindset
  • Writing tests for the first

To begin with it was tricky to understand the structure and terminology of Microsoft fakes, let alone start testing my tricky CRM code.

Microsoft Fakes Introduction General

This section highlights content I found useful whilst learning about Microsoft Fakes in general without focusing on using Microsoft fakes with to Test CRM code.

A good, quick (7 minutes) video introduction to Microsoft Fakes

Below is a good general article on Unit testing with Visual studio

Writing Unit Tests for the .NET Framework with the Microsoft Unit Test Framework for Managed Code

Microsoft’s main page on Microsoft Fakes

Isolating Code Under Test with Microsoft Fakes

The Isolating Code Under Test with Microsoft fakes is a great introduction to fakes and it explains what Stubs and Shims and gives you some code examples.

Free Microsoft Fakes Ebook

Better Unit Testing with Microsoft Fakes

The ebook above gives a good introduction to Microsoft Fakes but the majority of the ebook is comparing Fakes to other testing frameworks, explaining how to convert your tests/logic from another testing framework to fakes.  It’s useful (and free) but for users getting started with Microsoft fakes you will probably stop reading half way through.

Unit testing with Fakes with Visual studio Premium 2012

This is a good article which is a good introduction to Microsoft fakes with the bonus of the source code being available for download.

CRM and Microsoft Fakes

The best single resource for getting started with writing unit tests using Microsoft Fakes and CRM is a series of 10 blog posts by Zhongchen Zhou

Dynamics CRM 2011 Unit Test Part 1: Introduction and Series Contents

This a fantastic tutorial, going through all the major elements in CRM you need Stub/Shim to enable testing of your CRM code.  Below are links to the fakes CRM testing.  I recommend clicking on the introduction which gives a description of each blog.

The examples are for CRM 2011 but CRM plugin development is based around the IOrganisationService and OrganizationServiceContext and these are still in the same in CRM 2015.

You can also download the source code shown in the tutorials in the link below


Having the code is useful because you can run the tests yourself and walk through the code to follow the unit testing flow (you can also copy parts of it into your unit tests)

Unit Testing Plugins using Microsoft Fakes

A short article which runs through setting up Microsoft fakes, it goes through all the steps to manually test a CRM plugin.  It has useful examples stubbing the IOrganisationService.

OrganizationService.RetrieveMultipleQueryBase = (query) =>
var result = new EntityCollection();
return result;

CRM 2015/2013 Testing Framework

Wael Hamze with help from Ramon Tebar (MVP) have done some great work and created a CRM 2015/2013 testing framework.  This is a framework for testing plugins/custom workflows.  The framework does a lot of mocking of the common plugin objects.

The framework is useful but I think the business logic code should be kept inside plugins.  I prefer to split it up into smaller focused classes and methods but I know a lot of people will be interested in testing the plugins, if so this project will speed up the process.

The project is very well documentated, so you should be up and running in no time.


Not only is this framework excellent but there are some very useful videos showing you how to use the framework

xRM Test Framework for Dynamics CRM 2015

Webcasts and Slides which has videos and presentation on the subject.  There is lots of source

 (Webinar Recording) – CRMUG SIG: Technical/Developer – Unit Testing Plug-ins in Dynamics CRM 2013 (June 2014)

 Technical/Developer – Unit Testing Custom Workflow Activities in Dynamics CRM 2013 (July 2014)

Technical/Developer – Integration Testing Plug-ins in Dynamics CRM 2013 (July 2014)

Books (Unit testing in general)

I’m not qualified to say what books are good but I’m reading and enjoying

The Art of Unit Testing: with Examples in .NET


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


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.


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 CRM Developers should unit test their code

I haven’t written any unit tests for quite some time but I have decided to get back on the testing band wagon.  I will be writing more blog posts on unit testing but I thought I would start with a blog post about the benefits of unit testing.

When you mention unit tests to CRM developers or any developers is a bit of Marmite question.  Some developers love unit tests and some developers dislike writing unit tests and there isn’t much in the middle.

I believe most developers know they are beneficial but because they involve the tricky/boring setting up testing data and if you don’t write tests regularly they can seem difficult to write.

Writing Unit tests will mean you have more code to maintain but the benefits greatly out weight the negatives.

My experiences of unit testing and CRM projects is a lot of CRM practices are not using unit tests (I said this is my experience) or some of them write a few tests but this is usually down to the individual developer rather than a company process.

Why don’t CRM Developers unit test

Here are some of the common reasons/excuses

  • It takes too long
  • I haven’t got time
  • Integration tests will test the code
  • It’s too difficult to test CRM code because of PluginContext
  • The company doesn’t make unit testing compulsory

Benefits of Unit Testing

  1. You already test your code, make the tests reusable and available to others
  2. Tests prove the code works
  3. Unit Tests make you try to break and then fix your code
  4. You can make big changes to the code and test the code still works
  5. The tests can be run every time the code is changed
  6. Testing is not slower
  7. Writing code to be tested creates better code
  8. Testing reduces the number of bugs in the code
  9. Refactoring the code can be done easier and with confidence
  10. It’s great when you get a green light
  11. Unit tests make the code more readable and understandable
  12. Testing before you code helps improve the design of the code
  13. Writing unit tests stops coders block
  14. Less bugs make it out of Development
  15. Bugs unit tested stay fixed
  16. Unit Tests will help you when you have forgotten the business logic
  17. Changing code in one part of the system can break code in another part of the system
  18. You only write test for the required functionality

You already test your code, make the tests reusable and available to others

When a CRM developer writes some code he often tests the code either by creating a console app or by debugging the code (either using the plugin profiler or remote debugging on the server).

I know you are testing your code because you have to test the code before you deploy it.  A lot of CRM developers hope they will find the bugs by integration testing and testing the code from the front end (the CRM web application).

The problem with integration testing is it takes longer to test the code and you have to create the data and test the functionality again every time.

Once you write a unit test to test one part of your functionality you can rerun the test again and again, instead of having to run through the process manually.

Instead of writing a console app or debugging the code, unit tests will enable you have tests you can rerun and more importantly you will have tests other developers can read and run.  If in the future another developer has to fix some code in that area they will have tests to help document the code and will be able to make changes and test the code.

Tests prove the code works

Writing and running unit tests shows the code works and passes the tests.  This depends on you writing effective tests but most of the time you will write tests to test the functionality required.  If you are using Test Driven Development you will write the tests first and then write the code.

Unit Tests make you try to break and then fix your code

When writing unit tests developers will often try to break the code by passing in Null values or unexpected inputs.  These are easy tests to write and help reduce easy/lazy errors from entering the production system.

Often if you are not unit testing the code you don’t think to write defensive code because the main priority is to test the functionality required

You can make big changes to the code and test the code still works

One of the main benefits of writing unit tests is you have created tests to test the functionality.  This means you can change the code and run the tests again to see if it still works.  You can refactor the code with confidence you can test it.

This is an important point for developers who are scared changing some legacy code because they are not sure what code depends on what.

The tests can be run every time the code is changed

Code can get changed lots of time particularly if it’s in a core piece of functionality.  Having tests which can be easily and quickly run every time the code is changed will give you confidence nothing is broken.

When bug fixing often CRM Developers will fix parts of the code they didn’t work on or have little knowledge of.  Unit tests will give the CRM developer confidence their fixes haven’t accidentally broken the code.

Testing is not slower

It would seem logical to think writing units would make the process of writing code longer.  The truth is this isn’t true.  A lot of the time spent on code is fixing bugs after the initial development is done.  Unit testing will help you find more of these bugs up front and reduce the time spent bug fixing.

Writing code to be tested creates better code

When you write code which is easily testable it tends to be better designed and adheres to the single responsibility principle and the code is more modular and reusable.

The developer will also spend more time thinking and designing the code.  Code which is easy to test is easier to maintain and has loose coupling and dependency.

Testing reduces the number of bugs in the code

When a developer writes unit tests they test their code in a more systematic approach and testing various different scenarios.  When CRM Developers manually test their code they usually go follow one or two successful paths through the code.

Refactoring the code can be done easier and with confidence

Refactoring the code can be a lot more confidence when the developer can test the code with unit tests.

It’s great when you get a green light

It’s a great to write a test and then get the green light.  Not only is it a small win it’s great to see how many tests you have running against a piece of code.

Unit tests make the code more readable and understandable

Unit tests

Testing before you code helps improve the design of the code

Writing tests before you have written the code will help the developer think about the design of the code, what they are trying to achieve.

When thinking about writing tests for code the developer will try to simplify the code to make it easier to test.   This process will make the code easier to maintain, debug, extend and understand.

Writing unit tests stops coders block

Writing unit tests stops developers suffering from coders block.  Coders block is when a developers gets overwhelmed by the task of designing the code and doesn’t know where to start.  Writing units tests gets the developer writing code and gives the developer an easy place to start.

The developer can refactor and improve the design of the code later and will be able to test the code works with the unit tests.

Less bugs make it out of Development

CRM Development is complex and the code can contain many bugs.  The aim is to squash as many in the development environment as possible.  Unit testing is one of the tools used to find and fix bugs.

Code reviews and integration testing are the other two main bug detectors.

Unit testing won’t find all the bugs and doesn’t mean you don’t have to do code reviews and integration testing but it will help the CRM developer to find some bugs in his code.

Finding bugs in the development environment is quicker than finding bugs in a production environment, logging the bug, recreating the bug, debugging the code, fixing the bug, retesting and pushing the bug all the way back up towards production.

Bugs unit tested stay fixed

When you fix a bug and unit test the fix, it’s more likely to stay fixed and if it isn’t fixed it can quickly be tested again.

Unit Tests will help you when you have forgotten the business logic

Unit tests are a great way to document the code because you it’s easy to see what the code should be doing by looking at what the test is testing.

Business logic fades (quicker than you think) so a developer has a bug to fix the unit tests will help the developer understand what the code should do.  The CRM developer will be able to quickly test the code with the unit tests.

Changing code in one part of the system can break code in another part of the system

I call this “accidental bugging,” and
it seems to occur a lot near the end of a software project, when developers
are under pressure to fix existing bugs. Sometimes they introduce
new bugs inadvertently as they solve the old ones. Wouldn’t it
be great to know that you broke something within three minutes of
breaking it? We’ll see how that can be done later in this book.

You only write test for the required functionality

You only write unit tests to test for functionality required.  This is a good way to stop developers adding in extra functionality which might be needed in the future.

More reading on why you should unit test

Is Unit Testing worth the effort? 

I Pity The Fool Who Doesn’t Write Unit Tests

Top 12 Reasons to Write Unit Tests

Write Maintainable Unit Tests That Will Save You Time And Tears