Microsoft Dynamics 365 Blog

As a software developer, you are expected to write lines and lines of code, spending long hours writing big chunks of code and then delivering the chunks to be tested. This is a big job but now, just part of your job. In the last decade things changed dramatically for us developers. We have lots of tasks that didn’t necessarily exist ten years ago. For example, we now write code and then write programs that test the items we’re developing. This is what I’d like to briefly discuss here, displaying my personal experience on this issue.

For every line of code that ends up in the final product, I write 3-4 lines of code that test the functionality. I know this seems like a lot. Working in a product like Microsoft CRM poses a huge advantage for me to write test programs because CRM has such a rich extensibility store. For instance, if I change or add a feature in Workflow, I can develop a test that runs the following sequence:

1. Create a workflow rule, such as “Account on create”.
2. Add workflow steps, for instance, send email with a unique title (use a GUID in the title, for instance).
3. Activate workflow rule.
4. Then create and account.
5. See if the email was created, by checking if there’s an email with the unique title given at step.

The usual questions that we hear about “developers writing test code” are:

   a. Why should I do this if I can test it manually in 1/10th of the time?

Maybe testing manually once takes 1/10th of the time.  But if we test repeatedly and across multiple platforms and scenarios having a programmatic test ends up allowing us to test both faster more completely. Also, other people can run the test programs and the time savings will be multiplied by the number of developers.

   b. If I do the test program, what will testers do then?

Testers will test everything else that is not covered in our test programs. Be it performance, security, extensive code coverage, or simply check if the implementation actually followed the spec. It is a basic notion of quality: the person that does something cannot be the same person that validates it. And Microsoft values adhoc testing to find those pesky situation that a test code normally will not find.

   c. But I don’t have time to do this!

I can say for sure that when we do not test our code thoroughly before delivering to test, everything can and will be used against you. The time we save by not testing will bite you later with a vengeance when testers start to bang the app or, even worse, when found by the customer!

So whatever you code, consider the benefits of writing a testing procedure too. And make sure it works!

Lucidio Mayer Kuhn Filho

We're always looking for feedback and would like to hear from you. Please head to the Dynamics 365 Community to start a discussion, ask questions, and tell us what you think!