What is MC/DC?
Modified Condition/Decision Coverage, better known as MC/DC, is a code coverage criterion that satisfies the following:
- Each condition in a Boolean expression should take every possible outcome.
- Each decision takes every possible outcome.
- Each condition is shown to independently affect the outcome of the decision.
In writing unit test cases, MC/DC can be used to produce the optimal number of test cases to create while having the benefit of having a high, if not complete, code coverage (Decision coverage, Branch coverage and Condition coverage) result, thus resulting to a high quality output.
Somebody who wrote the Wikipedia article did a great job of defining MC/DC, you can read more here: https://en.m.wikipedia.org/wiki/Modified_condition/decision_coverage.
Basic Definitions and Examples
Condition
Conditions are atomic components of a Boolean expression. Take note that conditions should be atomic, this means that it should not contain sub-expressions.
An example: A && B, where “A” and “B” are condtions.
Decision
A Decision is composed of conditions, and zero or more Boolean operators. It is also the result of evaluating a Boolean expression.
An example using the expression above: If “A” is TRUE and “B” is FALSE, then the decision is FALSE.
Assumption(s)
Before anything else, let’s put on our assumption hat.
- We’re not dealing here with TDD (Test-Driven Development) approach, we’ll assume that the development is top-down. This means that code is already prepared for unit test creation.
The Benefits and How it Works
- As mentioned, MC/DC will produce the optimal number of test cases for a certain Boolean expression. The optimal number will be at least n+1 cases; where n is the total number of atomic conditions. Once you know the total number of test cases to generate, then most likely, you can come up with minimal test functions while enjoying the benefits of high code coverage results.
- The test cases generated from the evaluation of MC/DC can also provide a high percentage of code coverage. The branch coverage, decision coverage and condition coverage are few of the main items being covered by MC/DC. It ensures that for a specific function, the majority of the logic and lines are being covered. Code reviewer will be happy to review your logic and shy away with your noncompliance to project metrics.
- When you already have the MC/DC results, you don’t have to worry too much about missed out conditional scenarios and at the same time, you avoid redundant test cases. Of course, there are certain cases that might require to check for the validity of the logic, then in that case you should consider adding more logical test cases to ensure correctness of logic. Because you already know what scenarios to consider, it saves you and others a great deal of time, wherein you can invest that time into more pressing matters.
- You can identify which conditions are not being evaluated. This helps developers identify which part of their codes are unreachable and non-executable. Avoiding costly reworks when moving the product to a higher environment.
The cost of fixing a defect detected during unit testing is minor compared to the cost (effort, time and humilation) of fixing a defect in user acceptance and live environments.
Considerations
There is an argument that MC/DC methodology is only applicable and effective to perfect functions. Perfect functions are functions whose logic are correct and have zero to no chance of failing. It exists only in a perfect world.
This argument might be valid however, for functions whose logic will have to be updated after execution of unit test scenarios, the conditional logic can always be modified and right after, quickly come up with an updated optimal set of test cases once this methodology is mastered. Once mastered, the simplest form of Boolean expressions won’t require too much attention on which test cases to write (simple AND, OR, Exclusive OR and etc.), these are redundant scenarios and can be reused to any code. For a start, evaluate and compare old and new test scenarios and which ones are to be modified.
Conclusion
Learning how MC/DC works is a worthy investment for software development teams. A tool can also come in handy for large-scale/enterprise projects, where the number of conditions can go up to more than 20 (Yes! They exist – avionics and automotive industries. Some industries are getting complex also). It also comes in handy with other existing software development tools, which – in all honesty – can simplify the life of a developer.
There will be a learning curve for understanding the methodology, but once developers can get a hang of it, once they inculcate the knowledge and applied it, then they can just breathe MC/DC in and out when they do test creation activities.
Watch out for my next topic on how to simply and manually identify the test scenarios with the help of MC/DC.
If you liked this article and wish to receive more articles like this, follow me here and on Twitter. I am always willing to share my empirical knowledge of stuff that I’m passionate about.
Thank you and I hope you enjoyed the article!
You may wish to discuss about different tech and business stuff, drop an email to arjay.osma@gmail.com.
