This site is from a past semester! The current version will be here when the new semester starts.

Week 10 [Fri, Oct 16th] - Tutorial

1 Demo test coverage

Measure test coverage in your own IDE. Take a screenshot showing test coverage details such as lines covered, lines not covered, percentage of coverage for different files etc.

What

Can explain test coverage

Test coverage is a metric used to measure the extent to which testing exercises the code i.e., how much of the code is 'covered' by the tests.

Here are some examples of different coverage criteria:

Function/method coverage : based on functions executed e.g., testing executed 90 out of 100 functions.
Statement coverage : based on the number of lines of code executed e.g., testing executed 23k out of 25k LOC.
Decision/branch coverage : based on the decision points exercised e.g., an if statement evaluated to both true and false with separate test cases during testing is considered 'covered'.
Condition coverage : based on the boolean sub-expressions, each evaluated to both true and false with different test cases. Condition coverage is not the same as the decision coverage.

if(x > 2 && x < 44) is considered one decision point but two conditions.

For 100% branch or decision coverage, two test cases are required:

(x > 2 && x < 44) == true : [e.g. x == 4]
(x > 2 && x < 44) == false : [e.g. x == 100]

For 100% condition coverage, three test cases are required:

(x > 2) == true , (x < 44) == true : [e.g. x == 4]
(x < 44) == false : [e.g. x == 100]
(x > 2) == false : [e.g. x == 0]

Path coverage measures coverage in terms of possible paths through a given part of the code executed. 100% path coverage means all possible paths have been executed. A commonly used notation for path analysis is called the Control Flow Graph (CFG).
Entry/exit coverage measures coverage in terms of possible calls to and exits from the operations in the SUT.

Which of these gives us the highest intensity of testing?

a. 100% statement coverage
b. 100% path coverage
c. 100% branch coverage
d. 100% condition coverage

(b)

Explanation: 100% path coverage implies all possible execution paths through the SUT have been tested. This is essentially ‘exhaustive testing’. While this is very hard to achieve for a non-trivial SUT, it technically gives us the highest intensity of testing. If all tests pass at 100% path coverage, the SUT code can be considered ‘bug free’. However, note that path coverage does not include paths that are missing from the code altogether because the programmer left them out by mistake.

How

Can explain how test coverage works

Measuring coverage is often done using coverage analysis tools. Most IDEs have inbuilt support for measuring test coverage, or at least have plugins that can measure test coverage.

Coverage analysis can be useful in improving the quality of testing e.g., if a set of test cases does not achieve 100% branch coverage, more test cases can be added to cover missed branches.

Measuring code coverage in Intellij IDEA

Post a screenshot in the tutorial workspace document. An example is given below:

2 Exercise: interpret a sequence diagram

Do the following exercise, as guided by the tutor.

Explain the interactions depicted in this sequence diagram.

First, the createParser() method of an existing ParserFactory object is called. Then, ...

3 Exercise: draw a sequence diagram

Do following exercise. Remember to hand-draw the diagram and post a scan/photo in the tutorial workspace after you ar done.

Draw a sequence diagram to represent this code snippet.

if (isFirstPage) {
    new Quote().print();
}

The Quote class:

class Quote {

    String q;

    Quote() {
        q = generate();
    }

    String generate() {
        // ...
    }

    void print() {
        System.out.println(q);
    }

}

Show new Quote().print(); as two method calls.
As the created Quote object is not assigned to a variable, it can be considered as 'deleted' soon after its print() method is called.

Discuss answers, as guided by the tutor.