I'm sorry if the title is confusing, I don't know if what I am describing has a proper name so let me describe...

I have an algorithm which contains quite a bit of nested if/else if/else logic for detailed analysis of input data from the database. This is business logic that's inherently quite convoluted so there are odd special cases along the lines of "if the user has a cat then X=X+1" or even (because this is a 30-year-old application) "if the user has a cat then X=X+1, unless the cat has 3 legs".

Building mock data for unit tests is quite difficult, but more so ensuring we have a test case for each permutation - even a seemingly simple operation might have dozens of cases with various special business rules added over the years. My understanding is that an ideal approach is to decompose a large procedure into smaller ones for each permutation, because then we can determine if each procedure is called during the unit testing. However I can't realistically have every logic test if/else going into separate procedures.

Because this is tied into our specific data I was wondering about the analysis actually detailing what logic clauses/permutations were triggered, which code-path was followed. So you pass in an input, you get the analysis result but also a kind of metadata object describing the algorithm decisions made. I wondered if this might be referred to as "algorithm artifacts". It would mean I can then inspect the metadata from all unit tests and see which permutations might be missed, in order to create targeted test cases.

Does this idea have a name in the world of software engineering, that I might do further research?


1 Answer 1


This is called Branch coverage, and you find it in the Wikipedia article about Code coverage.

There are surely tools for some of the major development ecosystems which can measure the amount of code and branch coverage for a certain piece of code. What I don't know is if there are tools available which allow this in a programmatic manner, so a program of yours could easily determine all conditional statements in a piece of code and the number of times they have been triggered during a test run.

  • Thanks - I had not realised that modern code coverage tools seem able to give literal line-by-line coverage analysis, rather than just method-level. Very impressive.
    – Mr. Boy
    Commented Sep 30, 2022 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.