A short guide on Test Codeunits in BC testing and why you need them
January 17, 2023
J.F. Kennedy’s phrase “The time to repair the roof is while the sun is shining” hardly meant QA back in 1962. Now, in the technology world when customers need their tested, bug-free solutions yesterday, the famous saying surprisingly relates to future-proofing software with QA expertise.
When it comes to BC testing, autotests – or Test Codeunits – save time and accelerate the SDLC. And while businesses worldwide benefit from autotests, a solution many times faster and far more precise compared to manual checks, others are still hesitant about Test Codeunits.
As a true fan of automated testing, Global Mediator organized a Q&A session with our QA engineers on the most burning questions related to Test Codeunits to help you pick your flavor.
When do I need Test Codeunits in BC?
Ideally in NAV/BC, autotests are applied
When Microsoft releases mandatory BC updates
In CI/CD to merge code
After any bug fix to cover impacted areas with regression testing
After add-ons installations to verify BC standard checks and/or customizations
So, the slightest changes made to a software solution might impact the organization, making a proper solution testing a critical checkpoint.
Running Test Codeunits helps ensure that introducing new code does not break the existing one (this is especially relevant when building a new version of an extension). Autotests help identify blocker defects before deploying the build, enabling the team to timely fix the bugs with minimal impact.
You may also want to consider autotests for Business Central for the following reasons.
To substantially reduce the time for pre-testing and regression testing. Just imagine the time it takes for a QA specialist to manually click every new button added during customization for numerous environments. Test Codeunits prove to be a real gem here.
In case a BC functional customization is under constant and intensive development. You may face numerous customization requests. What is more, customization itself might be challenging, especially with complex dependencies and functionalities overlapping.
To get a full picture of testing from the very start and find the weakest points upstream instead of finding them at the verification stage. They indicate where tests break first, and where the problem is (like insufficient data, no setup, broken customization, etc.) The full picture helps to further analyze what might be wrong in a new environment and whether creating a bug or taking other actions is applicable.
In case a business expands. Expansion may relate to anything – from new business localizations to diverse modules like Sales, Purchase, Finance, Warehouse, Inventory, Manufacturing, etc., as well as their interdependent integration.
To run API testing (in addition to functional testing) and update testing (like the ones frequently pushed by Microsoft).
To multitask: in certain cases, it is possible to run autotests in parallel with manual testing on the same environment without the processes’ blocking each other.
To reuse the data, generated by Test Codeunits (e.g., spending minutes for each autotest instead of struggling for hours to manually test each case).
How will my business benefit from using Test Codeunits?
At first sight, it might seem that creating Test Codeunits is costly and time-consuming. In fact, Test Codeunits prove to be an excellent future-proof investment: you write them once and you can run them later as many times as needed. As practice shows, teams often need to shortly release a solution, or introduce any customizations, or apply the updates pushed by Microsoft, etc. Both the team and the customer face the dilemma of how to do it all on time without sacrificing the quality of the solution. Being armed with Test Codeunits enables the team to cover up to 50% of planned and required tests (up to 100% depending on the customization. In practice, the coverage is directly proportional to the extent of code covered by autotests). In case the software is built within CI/CD development cycle, Test Codeunits become a necessity to build and deploy the extensions.
With Test Codeunits for BC, you optimize manual routines and cut costs of testing in the long-term perspective since a defect cost increases exponentially unless you run the autotests.
Cost of fixing bugs: a defect cost increases exponentially over time
Who should create Test Codeunits?
This is one of the most popular questions related to automated testing. Test Codeunits are a type of code for test automation, which, by its nature, means a process run by code, not manual human activities. On the other hand, testing a feature implies knowing testing principles to cover it with test cases based on business requirements and impacted BC standard areas. It also implies being well-versed in Business Central flows to generate correct tests and prerequisites.
“When it comes to Quality Assurance services at Global Mediator, our team sticks to the principle: Do not divide responsibilities. Instead, combine the QA and Development teams’ efforts.”
- Ulyana Akdeniz, QA Lead at Global Mediator
One of Global Mediator’s values is the commitment to delivering a high-quality product in a short time. To nourish our values, each member of the team should do what they do best to deliver a solution. It means you do not need a one-man-band who can code, test, and knows business flow. It will most certainly take a lifetime to find such a pro. Meanwhile, good teamwork is the means to succeed in a short time: our approach to creating Test Codeunits is engaging both the Dev and QA teams.
How do I know that Test Codeunits had worked properly?
In a nutshell, to ensure the correctness of autotest, the QA and developer specialists responsible for the autotests implementation, cooperate to verify the tests that are being trialed/run/tested step by step. Firstly, the developer does the code review (as self-verification or with another developer); then provides comments to QA who then launches a test run in a test environment (including the localization specifics) and checks the test result received based on the expected result. The team checks the sequence of operations, impacted areas, autotests duration, and whether all the requirements had been covered with autotests and met successfully. To ascertain that the autotest works properly, the team creates a negative test case or creates special conditions to make the autotest fail (to catch a bug).
How do I make sure that Test Codeunits completely cover the customization?
This is when a Requirement Traceability Matrix comes into play to map the requirements, test cases, and code. One of the main conditions before writing the Test Codeunits: QA team gathers requirements and writes the test cases. It is necessary to properly mark each test against each respective requirement. The developers, in their turn, mark each autotest’s code with comments mentioning specific test cases and respective coverage marks for each test case.
What do I start writing Test Codeunits with if the legacy code keeps extending?
The key here is to start doing that (all you need for that are test cases). Test Codeunits work just as well with legacy code. The same outline with the developers’ coding and QA’s reviewing applies here. Based on the testing scope, the QA team can suggest running autotests if it is reasonable (as a rule, it is, since autotests considerably decrease the time for repeatable or identical tasks). When dealing with legacy code, the best practice to apply is to start by testing the functions most exploited by end-users, the most critical flow.
With autotests done by a reliable and tech-savvy team, you drive your solution’s release faster. Times faster compared to tedious and long-running manual testing. Also, far more reliable regarding the test results’ accuracy, readiness for the updates from Microsoft, and support of the CI/CD processes. Global Mediator is very much up for rocketing up your solution with profound development and testing expertise. What about you? Are you ready for a big jump?
Stay current with the latest insights from us