Picture Courtesy of: Dr. Sarah Ford How I Learned to Stop Worrying & Love the Bug
Project Management Clarification ¨ 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
Announcements ¨ 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 1 st 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
Terminology ¨ "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
Secret of Good Code
Secret of Good Code
Good Code Works
Write Code For Testing ¨ Quality of product decided by testing ¤ Testability critical design concern , for code to work
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
Test-Driven Development (TDD) ¨ Traditional coding practices changed from the start ¨ Write tests BEFORE begin implementation process Write stubs (but no code) for class & methods 1. Knowing correct outputs, write tests to check 2. Implement methods to pass your tests (& check often) 3.
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?
TDD Objections ¨ 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 Key Concept Check method’s results NOT method’s processes
Why TDD Helps ¨ 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
Unit Testing Library ¨ Most languages have x Unit 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
JUnit Test Cases Format ¨ 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 Annotations ¨ 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
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 assertEquals ( X expected, X actual) @Test method assertEquals ( float exp, float act, float tol) should result in assertEquals ( double exp, double act, double tol) calling 1 or more assertTrue ( boolean test) assert* statement. assertFalse ( boolean test) Assertion must not hold assertNull ( Object objTest) for method to fail. assertNotNull ( Object objTest) fail ()
Writing Test Methods ¨ 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
assertEquals With Decimals ¨ Computers actually very bad at math:
assertEquals With Decimals ¨ Computers actually very bad at math:
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?
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)
Tests Key Concept #1 Include tolerance (allowed rounding error) for floating point arithmetic checks
Math Checks With Decimals ¨ 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)
Test Method Outline Declare variable(s), create objects, & prep inputs 1. Call the method being tested 2. Use specification to verify returned value correct 3. Check fields for changes matching requirements 4. Can also verify other fields did not change 5. Assert array & object arguments also correct 6.
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; } This concatenates a & b public String sum() { return “Sum is ”+a+b; (like Strings) rather than } adding them. So 3 + 2 will } be 32 and not 5. Our tests need to find this!
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 ¨ 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()); }
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 ¨ 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”)); }
Recommend
More recommend
