Chapter 3 exersises

en por maku18blogen activity, TC3045, team, tostors
1.- Why do testers automate tests? What are the limitation of automation?
Developers automate testing to reduce costs and reduce human error, as well as making regression testing easier by allowing a test to be run repeatedly with the press of a button.
2.- Give a one-to-two paragraph explanation for how the inheritance hierarchy can affect controllability and observability:
Inheritance can make following input and output hard, since you have to keep track of multiple class definitions to be able to get an holistic view of what is going on when the tests are running. Sometimes there will be inheritance graphs so long that it feels like going up and down like a yo-yo, this yo-yo problem term was defined in «Problems in Object-Oriented Software Reuse» by Taenzer, Ganti and Poedar.
3.-Develop JUnit tests for the BoundedQueue.class.
public class BoundedQueueTest {
    /**
     * Test of enQueue method, of class BoundedQueue.
     */
    @Test
    public void testEnQueue() {
        System.out.println("enQueue");
        Object o = 1;
        BoundedQueue instance = new BoundedQueue(5);
        instance.enQueue(o);
        
        assertEquals(instance.toString(), "[1]");
    }

    /**
     * Test of deQueue method, of class BoundedQueue.
     */
    @Test
    public void testDeQueue() {
        System.out.println("deQueue");
        Object o = 1;
        Object a = 2;
        BoundedQueue instance = new BoundedQueue(5);
        instance.enQueue(o);
        instance.enQueue(a);
        instance.deQueue();
        
        assertEquals(instance.toString(), "[2]");
    }

    /**
     * Test of isEmpty method, of class BoundedQueue.
     */
    @Test
    public void testIsEmpty() {
        System.out.println("isEmpty");

        BoundedQueue instance = new BoundedQueue(5);

        assertEquals(instance.isEmpty(), true);
    }

    /**
     * Test of isFull method, of class BoundedQueue.
     */
    @Test
    public void testIsFull() {
        System.out.println("isFull");
        Object a = 1;
        BoundedQueue instance = new BoundedQueue(5);
        instance.enQueue(a);
        instance.enQueue(a);
        instance.enQueue(a);
        instance.enQueue(a);
        instance.enQueue(a);

        assertEquals(instance.isFull(), true);
    }

    /**
     * Test of toString method, of class BoundedQueue.
     */
    @Test
    public void testToString() {
        System.out.println("toString");
        Object o = 1;
        Object a = 2;
        Object b = 4;
        BoundedQueue instance = new BoundedQueue(5);
        instance.enQueue(a);
        instance.enQueue(b);
        instance.enQueue(o);
        assertEquals(instance.toString(), "[2, 4, 1]");
    }
}
queuetest
4.-Delete the explicit throw of NullPointerException in the Min program. Verify that the JUnit test for a list with a single null element now fails.
public class MinTest {
/**
* Test of min method, of class Min.
*/
    @Test(expected = NullPointerException.class)
    public void testMin() {
        System.out.println("min");
        List list = new ArrayList();
        list.add(null);
        Object result = Min.min(list);
    }
}
mitest
6.- Using the class PrimeNumbers describe 5 tests using the methods of the class to show the next points:
a) A test that does not reach the fault
b) A test that reaches the fault but does not infect
c) A test that infects the state but does not propagate
d) A test that propagates but does not reveal
c) A test that reveals a fault
For a test where we dont reach the fault we can call the method computePrime with a parameter less or equal to 0, being «computePrime(0).

This will never allow us to enter the while where we do the current operations and where the current fault is located.
For our second test, if we call the method with a parameter for example 3, being «computePrime(3)», the program will run the part of the code where our fault is at, but since the number doesn’t end with a 9, it doesn’t infects.
For our thrid test, if we call the method with a parameter that 19, it wont add the 19 as a primer number cause of the fault in the program. But since we are not executing the toString() for our PrimeNumbers class, even if it infects, it wont propagate and the user wont realize, even if we allready have a wront value thanks to the fault.
For the fourth test, would be the same as the last case, but this time we would use the method toString() causing this to make the user realize about whats wrong in the execution (if it has some of the values to compare with the current result).
Only when the user realizes of this (by the same test result comparation) would be in the reveal stage, if not, it would stay in the propagate stage.
7.- Recode the class using the Sieve Approach, but leave the fault. What is the first false positive, and how many «primes» must a test case generate before encountering it? What does this exercise show about the RIPR model?
If you want to see the exercises’ code in our repository you can visit it here:

Deja un comentario