CS 458 - Week 5 Labs - 2017-09-20

A little intro to JUnit and a little demo of attempted
TDD (Test-Driven Development)

USER STORIES!

-------
*   As a game player,
    I want to create a game die with a specified number
        of sides,
    so that I can use it in a game requiring dice
        with particular numbers of sides.

    estimate: 10 minutes

    acceptance criteria:
    *   verify that a newly-created die has the
        specified number of sides
-----
*   As a game player,
    I want to be able to see the current top of
       a game die,
    so that I can see what my latest roll was if
       it has been a while since I rolled it

    estimate: 5 minutes

    acceptance criteria
    *   verify that a newly-create die has a top of 1
    *   verify that the top reported is the value
        from the last roll
-----
*   As a game player,
    I want to roll a game die and see the result 
       (the number on its top),
    so that that roll result can determine what happens
        next in the game

    estimate: 20 minutes

    acceptance criteria:
    *   verify that a rolled die returns a value in
        [1, number of sides]
    *   verify that a rolled die's top is also the
        value returned from the latest roll
    *   verify that rolled die doesn't always return
        the same value
-----


*   (we are trying out JUnit 4.4 here)

*   In JUnit 4.4, these 3 packages are usually imported
    in a JUnit testing class:

    import static org.junit.Assert.*;
    import org.junit.Before;
    import org.junit.Test;

*   IN JUnit, you write a test class
    for each class;
    (and remember, you write the unit tests,
    however you are doing them,
    BEFORE writing the code to be tested)

    *   a common naming convention for a JUnit
        test class for class Blah 
	is BlahTest

*   Within JUnit, you typically create one or more
    instances of the class under test as private data
    fields of the test class
    *   seems like you'd want at least one for each
        overloaded version of the constructor

*   you usually use the JUnit @Before annotation on the line
    immediately before a public, void, no-argument method
    named setUp
    *   there is only ONE of these methods per JUnit test class

    *   this method will be run once before EACH unit test method
        (can reduce set-up work, because you don't need to do it
        WITHIN each test method)

*   The @Test annotation, put on a line immediately before a public,
    void, no-argument test method, signals that the method
    following is a JUnit unit test.

    *   EACH @Test method should test the functional
        correctness of ONE method in the corresponding
        Java class.

    *   traditional naming scheme: the word test followed
        by the name of the method being tested
        (but camelcase)

*   JUnit provides a whole class of assertion methods,
    in the class Assert, that can be used in these test
    methods

    *   assertEquals -
        expects an optional first argument, a String,
            giving the desired error message if this
            assertion fails,
	and an expected value,
	and an expression to test whose value should
	    EQUAL the expected value

    *   assertTrue -
        expects an optional first argument, a String,
            giving the desired error message if this
            assertion fails,
        and a bool expression that should be true
	    if this assertion is to be considered
	    successful

    *   here are more to look up if interested:

        assert
        assertFalse
        assertNotNull
        assertNotSame
        assertNull
        assertTrue
        fail
    
        ...and more