My Blog

Category: Uncategorized

  • Condition + branch coverage

    —

    by

    haroonkhan
    in ,

    Condition + branch coverage considers not only possible branches but also each condition of each branch statement. For example, the first if statement in the CountWords program contains three conditions: !Character.isLetter(str.charAt(i)), last == ‘s’, and last == ‘r’. Therefore, a developer aiming for condition + branch coverage should create a test suite that exercises each of those individual conditions being evaluated to true and false at least once and the entire branch…

  • Branch coverage

    —

    by

    haroonkhan
    in ,

    Branch coverage takes into consideration the fact that branching instructions (ifs, fors, whiles, and so on) make the program behave in different ways, depending how the instruction is evaluated. For a simple if(a && b) statement, having a test case T1 that makes the if statement true and another test case T2 that makes the statement false is enough to consider the branch covered. Figure 3.5 illustrates a…

  • Line coverage

    —

    by

    haroonkhan
    in ,

    A developer who aims to achieve line coverage wants at least one test case that covers the line under test. It does not matter if that line contains a complex if statement full of conditions. If a test touches that line in any way, the developer can count the line as covered.

  • Code coverage criteria

    —

    by

    haroonkhan
    in ,

    Whenever we identify a line of code that is not covered, we have to decide how thorough (or rigorous) we want to be when covering that line. Let’s revisit an if statement from the CountWords program. Listing 3.4 An if expression from the CountWords program A developer may decide to only cover the line —in other words, if a test passes through that if line, the developer…

  • Structural testing in a nutshell

    —

    by

    haroonkhan
    in ,

    Based on what we just did, let me define a simple approach that any developer can follow (see figure 3.4): Figure 3.4 Applying structural testing in a nutshell. Arrows indicate the iterative nature of the process. The diamond represents the moment where the developer decides whether to write the test case. The most important thing…

  • Code coverage, the right way

    —

    by

    haroonkhan
    in ,

    Consider the following requirement for a small program that counts the number of words in a string that end with either “r” or “s” (inspired by a CodingBat problem. Given a sentence, the program should count the number of words that end with either “s” or “r”. A word ends when a non-letter appears. The…

  • Introduction

    —

    by

    haroonkhan
    in ,

    We discussed using software requirements as the main element to guide the testing. Once specification-based testing is done, the next step is to augment the test suite with the help of the source code. There are several reasons to do so. First, you may have forgotten a partition or two when analyzing the requirements, and you…

  • The role of experience and creativity

    —

    by

    haroonkhan
    in ,

    If two testers performed the specification-based testing technique I described earlier in the same program, would they develop the same set of tests? Ideally, but possibly not. In the substringsBetween() example, I would expect most developers to come up with similar test cases. But it is not uncommon for developers to approach a problem from completely different…

  • How does this work with classes and state?

    —

    by

    haroonkhan
    in ,

    The two methods we tested have no state, so all we had to do was think of inputs and outputs. In object-oriented systems, classes have state. Imagine a ShoppingCart class and a behavior totalPrice() that requires some CartItems to be inserted before the method can do its job. How do we apply specification-based testing in this case? See the following listing.…

  • Requirements can be of any granularity

    —

    by

    haroonkhan
    in ,

    The seven-step approach I propose works for requirements of any granularity. Here, we applied it in a specification that could be implemented by a single method. However, nothing prevents you from using it with larger requirements that involve many classes. Traditionally, specification-based testing techniques focus on black-box testing: that is, testing an entire program or…