To be added to the pptx?

[Laoujin]

Code Coverage vs Branch Coverage

Code Coverage / Statement Coverage: The percentage of source code that is executed by the tests. It is useful to identify which parts of the code are untested and might contain undetected bugs. It is easy to calculate and is one of the metrics of SonarQube.

Branch Coverage / Decision Coverage: To have complete “Branch Coverage” all possible routes through the code need to be tested. This reveals bugs that 100% Code Coverage alone cannot and ensures that all possible scenarios are covered by UnitTests.

It is therefor important to create all the UnitTests that are needed to get to complete Branch Coverage.

Example

Given the following method:

if (condition) {
} else {
}
if (condition2) {
} else {
}

• For 100% Code Coverage, we need 2 UnitTests, for example
  • Test1: condition1 & condition2 are true
  • Test2: condition1 & condition2 are false
• For 100% Branch Coverage, we need 4 UnitTests, for example
  • Test1: condition1 & condition2 are true
  • Test2: condition1 & condition2 are false
  • Test3: condition1 is true & condition2 is false
  • Test4: condition1 is false & condition2 is true

Example 2

if (cond1 && (cond2 || cond3)) {
}

To attain a good Branch Coverage it’s best to have a test that covers these cases:

• cond1 is false
• cond1 is true and cond2/3 are false
• cond1/2 are true and cond3 is false
• cond1/3 are true and cond2 is false

When cond1 is already false, you could still cover all different cases for cond2/3 but, it doesn’t really matter since they are not being evaluated. Because these are white box tests, this is OK. If this is somewhat tricky/important code, subject to change, or in a part of the code in which bugs have been previously encountered, you may still want to write a test for all cases.

State Testing vs Behavior Testing

State Testing:

Given a certain input, check that the correct output is produced. Examples:

• When doing a calculation: assert that the response is correct
• When retrieving data with a Request object: assert that the correct records are returned
• When the database is updated: assert that the entities are in the expected end state

Behavior Testing:

Given a certain input, check that certain object interactions did or did not happen. Typically used when dealing with external systems. Examples:

• When doing a calculation: verify that an emergency is raised when the calculation fails. Also verify that no emergency is being raised when the calculation succeeded!
• When retrieving data with a Request object: verify that an email is sent when data is requested that is not available (but should’ve been)
• When the database is updated: verify that the DbContext.Save method is called

Equivalence Partitioning and Boundary Value Analysis

Simple case: we expect an EnergyAmount to be between 0 and 100.

Equivalence Partitioning:

With the following 3 tests:

• An invalid low value <0 (example: -10)
• A correct value (example: 20)
• An invalid high value >100 (example: 200)

We have partitioned the data into 3 sections. It is not needed to create additional low/correct/high values since they all belong to the same 3 partitions we already covered.

Boundary Value Analysis:

There are only two hard problems in Computer Science: cache invalidation, naming things, and off-by-one errors.

This is where Boundary Value Analysis comes into play. Instead of just checking our semi-random values for the Equivalence Partitioning, we might add (or replace) them with boundary values to ensure that we haven’t made any accidental off-by-one errors. We could add the following test cases:

• Values -1 and 0
• Values 100 and 101

Edge Case Testing:

This could be considered a case of Boundary Value Analysis. In the EnergyAmount example, also create a test using NULL as input. You could also define the behavior of PositiveInfinity, NegativeInfinity and NaN EnergyAmounts – if this makes sense for your UseCase!

[Laoujin]

Also to be added:

• Sociable tests (see book MicroServices)
• Mockist vs Classicist testing (see Fowler)

This is a bit the discussion: should UnitTest be for one class and mock everything else? Or should you mock only things that are slow / tricky?

Other things that are missing:

• Documentation: a failing test should tell you tell you, on a pretty detailed level, what exactly is broken

[Laoujin]

And well, maybe just throw everything in ChatGPT and see if it comes up with anything it thinks is still missing?