Simple systems are not feasible because they require infinite testing. Norman Ralph Augustine
Developers must be able to isolate and test their code easily and often in their own development environment. If you don’t test your code you will let more bugs into production environments and this will cost you more time and effort in the long term.
Developers must be proud of their work, be craftsman and create quality code. Poor quality code is a drop in standards which can spread to multiple developers like a virus – Bad code is like a virus, don’t get infected. As a team/group you can choose to raise standards and get all members to raise their game or you can let standards drop.
Keep your standards high, your code quality and Never leave a CRM developer stranded
I get questions from Hsok CRM blog readers asking me to resolve problems they are having or asking for advice. Below are two good examples
- Questions on Microsoft Dynamics CRM solutions and environments
- How do multiple developers work on a web resource within the CRM
If I could offer some advice about asking questions
- Be polite, say hello, how much you love my blog and then your question 🙂
- Investigate the problem yourself first. Google the problem, try things, ask your friends/colleagues and then if you still have problems ask the problem on the CRM forum
- Provide me (and the CRM forum) with as much information about the problem as possible e.g. CRM version, what you are doing and why, what you have tried, the results of your research. More information = greater chance of someone/me helping you.
I received an email from Martin who had read my blog posts on unit testing with Microsoft Dynamics CRM
- Experiences of Unit testing with Microsoft Dynamics CRM Projects
- Why CRM Developers should unit test their code
- Unit tests are a vital part of emerging code design
- Information to Get started with Unit Testing with Microsoft Fakes and Microsoft Dynamics CRM
Martin was working on writing a webservice and found unit testing was a great way to test the logic of the code without having to deploy the code in the production environment which was tricky.
Isolate the logic of your code
Logic is the beginning of wisdom, not the end. Leonard Nimoy
Unit testing is about isolating and testing the logic of your code. The main benefits of unit testing
- You think about designing and structuring your code to make it easy to test the logic
- You and any developers can rerun your tests
- It’s easier to refactor the code because you can test it still works.
- Developers who unit test, think more about what they are testing
Thinking about what you are doing, questioning how you are designing the code and thinking about what the code is doing helps create better code.
First draft code works but is sloppy and complex with lots of dependencies. First draft writing, you must edit your work to remove sloppy code and improve the overall code quality.
UNIT TESTING ALLOWS YOU TO EDIT CODE AND BE ABLE TO TEST THE CHANGES
If you haven’t got unit tests, you might break the code and not know about it, unless you test the code and all areas which uses the code.
How do you know the logic works
When a junior developer has written a plugin, web service or piece of code, I always want to know how they have tested the code works.
Before I started writing unit tests, I used to have a console application which connected to the development CRM environment and ran my plugin code. I could do this because I wrote the plugin code as a separate piece of code which was passed a CRM connection and entity.
If you cannot run through the logic of the code on your own dev environment then you are making it difficult to test. Difficult tasks are often not done by developers short on time.
Unit tests are the best way to test the code but a console app so you can step through the code is a good second.
Martin’s email about the
Use Case for Mocking WebServices
Unit Testing is at first somehow abstract but we had some requirements to use a 3rd party WebService, where Mocking saved us a lot of time.
The WebService-Provided only allowed connection from whitelisted IP’s. Our customer only ordered the smallest Internet Package from his ISP.
Every 24 hours the customer had a new public IP. So we couldn’t get a connection form the cooperate network. Upgrading the ISP-Packing was also impossible.
The Webservice-Provided refused to add the whole ISP-Subnet. Our customer had already an Azure Cloud Service with a reserved (static) IP. So we decided to deploy our Code there.
Deploying and debugging is somewhat unhandy in this scenario. It take approximately 15 Minutes to deploy the Cloud Service and start Debugging.
I decided then to Mock the SOAP-Service so I could easily develop locally. This was a big time saver.
Maybe this Story helps other to understand what you can also address with Unit Tests/Mocking. Another possible Use Case for it is when you only have a production System and don’t wan’t to mess it up or when you must pay for every requets you submit to the 3rd Party WebService.