How I Learned to Stop Worrying & Love the Bug Project Management - - PowerPoint PPT Presentation

How I Learned to Stop Worrying & Love the Bug

Picture Courtesy of: Dr. Sarah Ford

¨ Your project manager is in charge of your project

¤ They are your manager

¨ You write the user stories for your project

¤ Your PM will choose which stories you will complete each

sprint

¤ Your PM will decide which tasks are assigned to whom

¨ Not all PMs will manage projects the same way

¤ This is expected ¤ They are given some amount of freedom to decide the

best approach for a particular team

¤ All projects are different and will require different

approaches

Project Management Clarification

¨ Course focused on software engineering concepts

¤ “Make cool stuff” nice, but already know capable of this ¤ Trying to develop experience & skills on important topics ¤ Rubric (& scores) reflect emphasis; efforts should follow

¨ Even for 1st sprint, project grows around user stories

¤ Write many more stories than sprint will complete ¤ Improve grade by checking stories written correctly ¤ Create & use tasks to complete work for each sprint ¤ Task & acceptance tests yield “perfect” product

Announcements

¨ "Acceptance tests" check user story complete

¤ Ensures feature works and ready for deployment ¤ Run by client as part of release demo ¤ Ensure full understanding of all aspects of feature

¨ "Task tests" check that a task is complete

¤ Ensures task complete and ready for inclusion ¤ Run by developers in preparation for daily stand-up ¤ Finds bugs during coding & through later changes ¤ Also defines what success like to enable parallel work

Terminology

Secret of Good Code

Secret of Good Code

Good Code Works

¨ Quality of product decided by testing

¤ Testability critical design concern, for code to work

Write Code For Testing

Test-Driven Development (TDD)

¨ Very popular technique developing software

Tests We Usually Write

Tests We Should Write

Tests We Should Write

Tests We Should Write

¨ Traditional coding practices changed from the start ¨ Write tests BEFORE begin implementation process

1.

Write stubs (but no code) for class & methods

2.

Knowing correct outputs, write tests to check

3.

Implement methods to pass your tests (& check often)

Test-Driven Development (TDD)

Common Objection To TDD

But…

How could I write tests before I know

what the

method does?

Smart Programmer Responds… How could you write the code before you know

what the

method must do?

¨ Feels weird to start with tests when you first try… ¨ .. but objections reflect poor habits checking code

¤ Know method’s outcomes when starting to write… ¤ … but you may not know how it will be done

TDD Objections

TDD Key Concept

Check method’s results NOT method’s processes

¨ Many benefits when test cases created first

¤ Clarify what method does so coding becomes easier ¤ Since written for tests, methods become easier to fix ¤ Know when code done by checking if tests pass

¨ Studies have found that TDD simplifies debugging

¤ Know when bug created by running tests regularly ¤ Tests start to fail after writing 1 line: bug on that line ¤ Bugs… somewhere(?) when hours pass before testing

Why TDD Helps

¨ Most languages have xUnit library for unit testing

¤ Tests written in language so can run anywhere ¤ Strong support that makes writing tests very easy ¤ Supported by most IDEs (e.g., Eclipse, IntelliJ, BlueJ) ¤ Started with Java – JUnit still gold standard for testing

¨ Automation important to allow frequent testing

¤ Testing easy – just select “Run As…” “JUnit test” ¤ Green means good – checking results also very easy ¤ Easy to see problems – see red when tests fail

Unit Testing Library

¨ Most often write test class for each class

¤ Identical to other classes; usually named ____Test ¤ As regular class, can use inheritance & have fields ¤ Inheritance & fields not required like any Java class

¨ Since ver. 4.0, JUnit’s annotations identify tests

¤ Extra information added to show method is test case ¤ Annotation added immediately before method

JUnit Test Cases Format

¨ Loop until all test cases in class are executed

¤ JUnit executes all methods marked @Before

n Optional methods initialize any data before each test

¤ Run exactly 1 method labeled @Test executed ¤ Executes all methods marked @After

n Also optional, cleans mess made by @Before

JUnit Annotations

assertEquals(X expected, X actual) assertEquals(float exp, float act, float tol) assertEquals(double exp, double act,double tol)

assertTrue(boolean test) assertFalse(boolean test) assertNull(Object objTest) assertNotNull(Object objTest) fail()

Statements Performing Checks

assertEquals(X expected, X actual) assertEquals(float exp, float act, float tol) assertEquals(double exp, double act,double tol)

assertTrue(boolean test) assertFalse(boolean test) assertNull(Object objTest) assertNotNull(Object objTest) fail()

Statements Performing Checks @Test method should result in calling 1 or more assert* statement. Assertion must not hold for method to fail.

¨ Test methods MUST have @Test annotation

¤ Non-static, void methods only for JUnit to work ¤ By same logic, test methods cannot have parameters

¨ Uses normal code to write these test methods

¤ Just normal methods; can contain any legal Java code ¤ Conditionals and loop statements occasionally included ¤ Can instantiate objects and call methods on objects ¤ Other methods can use assert___ & be called by tests

Writing Test Methods

assertEquals With Decimals

¨ Computers actually very bad at math:

assertEquals With Decimals

¨ Computers actually very bad at math:

¨ Computers actually very bad at math

¤ Decimal numbers hard & imprecision always created ¤ Not limited to computers: can you write 2/3 as decimal?

Math Checks With Decimals

¨ Computers actually very bad at math

¤ Decimal numbers hard & imprecision always created ¤ Not limited to computers: can you write 2/3 as decimal?

¨ Must specify tolerance for decimal comparisons

¤ float or double equal if difference below tolerance

assertEquals(float expect, float act, float tolerance) assertEquals(double expect, double act, double tolerance)

Math Checks With Decimals

Tests Key Concept #1

Include tolerance

(allowed rounding error)

for

floating point arithmetic checks

¨ Examples of this in use:

float act = 0.2; assertEquals(0.3, act, 0.01); assertEquals(10.1, act, 10.00);

¨ Tolerance depends on problem & precision needed

¤ If unclear, just pick reasonable value (Dr. Hertz uses 0.001)

Math Checks With Decimals

Test Method Outline

1.

Declare variable(s), create objects, & prep inputs

2.

Call the method being tested

3.

Use specification to verify returned value correct

4.

Check fields for changes matching requirements

5.

Can also verify other fields did not change

6.

Assert array & object arguments also correct

Class To Be Tested

public class Operational { private int a, b; public Operational(int fst, int snd) { a = fst; b = snd; } public String multiply() { int product = a * b; return “Product is ”+product; } public String sum() { return “Sum is ”+a+b; } }

Class To Be Tested

public class Operational { private int a, b; public Operational(int fst, int snd) { a = fst; b = snd; } public String multiply() { int product = a * b; return “Product is ”+product; } public String sum() { return “Sum is ”+a+b; } }

This concatenates a & b (like Strings) rather than adding them. So 3 + 2 will be 32 and not 5. Our tests need to find this!

¨ Traditionally, test class adds “Test” to class name

¤ Each case is method having @Test annotation

public class OperationalTest { @Test public void testMult0() { Operational xByZero = new Operational(3, 0); Operational zeroByX = new Operational(0, 17); assertEquals(“Product is 0”, xByZero.multiply()); assertEquals(“Product is 0”, zeroByX.multiply()); }

Starting Test Cases

¨ Traditionally, test class adds “Test” to class name

¤ Each case is method having @Test annotation

public class OperationalTest { @Test public void testMult0() { Operational xByZero = new Operational(3, 0); Operational zeroByX = new Operational(0, 17); assertEquals(“Product is 0”, xByZero.multiply()); assertEquals(“Product is 0”, zeroByX.multiply()); }

Starting Test Cases

¨ Traditionally, test class adds “Test” to class name

¤ Each case is method having @Test annotation

public class OperationalTest { @Test public void testMult0() { Operational xByZero = new Operational(3, 0); Operational zeroByX = new Operational(0, 17); assertEquals(“Product is 0”, xByZero.multiply()); assertEquals(“Product is 0”, zeroByX.multiply()); }

Starting Test Cases

¨ Only get to know test failed with assertTrue()

@Test public void yuckyButLegal() { Operational xByOne = new Operational(-2, 1); assertTrue(xByOne.multiply() .equals(“Product is 2”)); }

Bad Tests to Write

¨ Only get to know test failed with assertTrue()

@Test public void yuckyButLegal() { Operational xByOne = new Operational(-2, 1); assertTrue(xByOne.multiply() .equals(“Product is 2”)); }

Bad Tests to Write

¨ Get more detailed results with assertEquals()

@Test public void muchImproved() { Operational xByOne = new Operational(-2, 1); assertEquals(“Product is 2”, xByOne.multiply()); }

Better Tests to Write

¨ Get more detailed results with assertEquals()

@Test public void muchImproved() { Operational xByOne = new Operational(-2, 1); assertEquals(“Product is 2”, xByOne.multiply()); }

Better Tests to Write

Tests Key Concept #2

Use assertTrue() & assertFalse()

• nly for boolean

values & properties

¨ Must be certain assert___ testing YOUR code

§

@Test public void whatAmITesting() { Operational xByOne = new Operational(-2, 1); assertEquals(“Product is -2”, “Product is ” + (-2 * 1)); }

More Test Gotchas

¨ Must be certain assert___ testing YOUR code

§

@Test public void whatAmITesting() { Operational xByOne = new Operational(-2, 1); assertEquals(“Product is -2”, “Product is ” + (-2 * 1)); }

More Test Gotchas

¨ Must be certain assert___ testing YOUR code

§

@Test public void whatAmITesting() { Operational xByOne = new Operational(-2, 1); assertEquals(“Product is -2”, “Product is ” + (-2 * 1)); }

More Test Gotchas

Other Version of Gotcha

Test Method Outline

1.

Declare variable(s), create objects, & prep inputs

• 2. Call the method being tested

3.

Use specification to verify returned value correct

4.

Check fields for changes matching requirements

5.

Should also verify other fields did not change

6.

Assert array & object arguments also correct

¨ Will this pass?

@Test public void passingIsNotFailing() { Operational xByOne = new Operational(-2, 1); xByOne.sum(); }

More Test Gotchas

¨ Will this pass?

@Test public void passingIsNotFailing() { Operational xByOne = new Operational(-2, 1); xByOne.sum(); }

More Test Gotchas

Tests Key Concept #3

Every @Test method

should execute

AT LEAST 1

assert_____()

¨ Often make assumptions when writing code

¤ True writing code and still true writing test cases ¤ Passing ≠ correct; could be no tests were run ¤ May not check what you think; care needed writing tests

¨ Tests should be written & run before coding

¤ Tests must fail, since code has not yet been written!

¨ Before wasting time, always check assumptions

Assumptions Deadly

Valid Issue; Invalid Objection

¨ Hardcode assert___ expected value if it is possible

@Test public void shouldNotPassButDoesPass() { Operational xByOne = new Operational(-2, 1); assertEquals(“Sum is ” + -2 + 1, xByOne.sum()); }

Hardcode Your Checks

¨ Hardcode assert___ expected value if it is possible

@Test public void shouldNotPassButDoesPass() { Operational xByOne = new Operational(-2, 1); assertEquals(“Sum is ” + -2 + 1, xByOne.sum()); }

Hardcode Your Checks

¨ Hardcode assert___ expected value if it is possible

@Test public void nowFindsBug() { Operational xByOne = new Operational(-2, 1); assertEquals(“Sum is ” + -2 + 1, xByOne.sum()); assertEquals(“Sum is -1”, xByOne.sum()); }

Hardcode Your Checks

Tests Key Concept #4

Make tests valuable

HARDCODING

EQUALS

KNOWING

Evaluating Test Efforts

¨ Develop tests with detailed look at the algorithm ¨ Test coverage discussed often by people, but… ¨ … coverage can be measured many ways

Statement coverage Run each statement at least once Branch coverage Run each branch at least once Path coverage Run each possible branch combination at least once

Detail Increases

Coverage Measures

1 2 3 5 4

All Statements: 1, 2, 3, 4, 5 All Branches: 1, 2, 3, 4, 5

1, 3, 5

All Paths: 1, 2, 3, 4, 5

1, 2, 3, 5 1, 3, 4, 5 1, 3, 5

¨ Cannot prove there are no bugs

How To Write Tests

¨ Cannot prove there are no bugs

How To Write Tests

Testing shows the presence, not the absence

• f bugs

¨ Cannot prove there are no bugs

¤ Can only show no bugs exist on those tests

How To Write Tests

Testing shows the presence, not the absence

• f bugs

¨ Start working on Sprint 1

¤ Break stories into tasks ¤ Remember the tests! Tests validate your understanding ¤ Coding can wait! Only prototype required for 1st sprint

For Next Lecture