The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 release wave 1Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 TimelineWatch the 2020 Release Wave 1 virtual launch event
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 | Upcoming TechTalks
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
If I could offer some advice about asking questions
I received an email from Martin who had read my blog posts on unit testing with 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.
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
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.
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
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.
If any other readers have stories about problems overcome or interesting solutions to problems please write to me at firstname.lastname@example.org
Business Applications communities