1. CSC 395 – Software Engineering Lecture 10: Execution-based Testing –or– We can make it better than it was. Better...faster...agiler

2. Today’s Goal Discuss execution-based testing When this testing should be performed Who should do this testing What this testing should entail Discuss Java-based testing approach

3. Who Should Do The Testing Original Programmer Deadline-focused Job requires writing correct code quickly Believes code correct Familiar with code Testing Team Member Quality-focused Job requires finding all faults Assumes faults exist No knowledge of code

4. When Should Testing Occur Turns out, agile methods not all bad Testing process begins before coding Develop unit tests before coding Check that individual classes/methods work Part of transition from design to development Helps developers understand design Focuses developers thoughts before coding Enables simple checks during coding process These tests are a first unofficial step

5. What Should Test Case Do? Want to limit number of test cases Each test case takes time (e.g., $$$$) Reasonably expect each test to find an error Why test something that would not find an error? Must know which error test would find What is value of test if it does not solve problems? Tests should not do too much Results of complex tests are hard to understand Keep collection of “best practice” tests

6. Testing Strategy Tests begin at finest possible granularity Focuses debugging on fewest lines of code Enables testing to begin as soon as possible Slowly builds up to highest level tests Unit tests look at class/method level Simple tests run regularly during coding session Integration tests examine class interactions System/validation tests looks to see entire system works & fulfills client’s requirements

7. Assertions in Java Test that boolean property holds Place anywhere in a method Tested * each time method executed, so can slow performance Very useful for internal, α, & β programs Assertions added or removed at runtime java –ea runs program while testing assertions Assertions ignored when –ea flag not specified Can document & test assumptions in code But not good for unit tests or finding source

8. Automated Unit Testing Automation important on large projects Allows continued testing as code written Prevents regression failures JUnit popular system for unit testing Written in Java and incorporated into Eclipse Performs tests on individual classes Limits code used when performing checks Testing starts immediately Tests flow from design documents

9. Writing JUnit Tests Define test class for each class Each test case should become method JUnit automatically runs all tests in a class Eclipse executes all test classes in a project Relies on Java annotations Adds information to individual methods Relative new to Java, but growing in popularity Especially good for large projects or when performance is crucial

10. Running JUnit Tests Each class executes @BeforeClass method At most 1 method can have annotation For each method marked @Test Run all methods marked @Before These perform any necessary setup Execute one @Test method Run all methods marked @After Close files and other cleanup from @Before Finally, execute @AfterClass method

11. JUnit assert____ Methods Actual tests performed using these methods assertTrue(boolean test) assertFalse(boolean test) assertSame(Object expected, Object actual) assertNotSame(Object expected, Object actual) assertNull(Object object) assertNotNull(Object object) fail()

12. Other Important Tests Tests better fail before code is written But do not want to see these as failures @Ignore annotation tells JUnit to skip test Tests must also check methods fail correctly Declare exception to be thrown in annotation: @Test(expected=MyException.class) Test passes only when MyException thrown

13. For Next Lecture Discuss object-orientation approach Goals of OO-based languages Important features of OO-based software How OO goals used in software engineering Begin thinking about next stage of project Must develop analysis & design from your requirements document These are make-or-break parts of any project