When to use automated testing?
Enough arguments to convince you why you would want to use automated tests, I guess. But how about when to use them? Ideally, this would be whenever code is changed to show that this functionality, which has already been tested, is still working as it should, to show that recent modifications have not compromised the existing application.
This sounds logical, but what does this mean when you have no automated tests in place? How do you go about starting to create your first ones? Basically, I would advise you to use the following criteria:
- What code change will give the highest return on investment when creating automated tests?
- For what code change will your test automation creation improve your test coding skills the most?
Using these two criteria, the following examples of code changes are typical candidates for your first efforts:
- After go-live bug fixing
- Buggy code
- Frequently modified code
- Business-critical code being changed
- Code with no or low dependencies
- Refactoring of existing code
- New feature development
- Microsoft updates
After go-live bug fixing
An after go-live bug reveals an omission in the initial test effort that can often be traced back to a flaw in the requirements. Frequently, it has a restricted scope, and, not the least important, a clear reproduction scenario. And by all means, such a bug should be prevented from ever showing its ugly face again.
Buggy code
You have this feature that keeps on troubling you and your customers. Bugs keep on popping up in this code and it never seems to stop. The most elementary thing you should start with is the after go-live bug fixing approach as previously discussed. But, even more importantly, use this code to get started on your first test suite.
Bugs are a particularly useful starting point because they usually provide the following:
- A defined expectation
- Steps to reproduce the scenario
- A clear definition of how the code fails
These are three important elements of automated testing, as you will learn in the next few chapters.
Frequently modified code
One of the basic rules of good code governance is that code should only be changed when it is going to be tested. So, if the code is modified frequently, then the consequence is that it will also be tested frequently. Automating these tests will give a good return on investment for sure.
Business-critical code being changed
Thorough testing should always be the case, but, given the circumstances, it is unfortunately not always doable. Testing changes made to business-critical code, however, should always be exhaustive; that is, try to cover all scenarios of those processes and define a test for each one of them in your automated testing. You can simply not afford any failures on them. Make it a point of honor to find even the two to five percent of bugs that statistics tell us are always there!
Refactoring existing code
Refactoring code can be nerve-racking: removing, rewriting, and reshuffling code. How do you know it is still doing the job it used to? Does it not break anything else? It certainly needs to be tested. But, when manually done, it is often executed after the whole refactoring is ready. That might already be too late, as too many pieces got broken. Before refactoring any code, grant yourself peace of mind and start by getting an automated test suite in place to prove its validity of the original code. To achieve this, define the business scenarios and create tests for each of those scenarios to prove that the current functionality works. With every refactor step you take, run the suite. And again, to show the code is still behaving the same. This way, refactoring becomes fun. We will elaborate on refactoring more later.
New feature development
Starting from scratch and creating a new feature, writing both test and application code, will be an undeniable experience. For some, this might be the ultimate way to go. For others, this is a bridge too far, in which case, all previous candidates are probably better ones. In Section 3, Designing and Building Automated Tests for Microsoft Dynamics 365 Business Central, we will take this approach and show you the value of writing test code alongside application code.
Microsoft updates
Incorporating any update from Microsoft, be it on-premises or in the cloud, your features must be (re)tested to prove they're still functioning as before. In case you do not have automated tests in place, begin creating them. Do this based on the analysis of the various changes and the risks they might entail in terms of introducing errors.
Note
Working on test automation for a new feature will give you the best return on investment. It will lead to a better quality of the code and thus prevent a lot of bugs after go-live/release. But it might be too big a threshold when you start with test automation. Choose one of the above-suggested candidates to start your test automation battle.
