CSC 395 –Software Engineering

Lecture 10:

Execution-based Testing –or–

We can make it better than it was. Better...faster...agiler

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

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

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

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

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

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

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

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

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

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()

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

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