UNIT TESTING 3 / 8 1 / 8 Unit testing involves: Lots of small, - - PowerPoint PPT Presentation

UNIT TESTING

3 / 8 1 / 8

Unit testing involves:

Lots of small, independent tests Reporting passes, failures, and errors Some optional setup and teardown shared across tests Aggregation (combining tests into test suites)

3 / 8 2 / 8

WHY WRITE A UNIT TESTING SUITE?

Misconception: It takes too much extra time to write the test suite!

Wrong! Empirical research repeatedly shows that test suites reduce debugging time more than the amount spent building the test suite.

1 / 8 3 / 8

SO, WHY WRITE A UNIT TESTING SUITE?

Unit Tests allows you to make big changes to code quickly: make the change, then click on “test”. If all green, then you know this module is all good. Unit Tests help you understand the design of the code you are working on

It forces you to think through the possible inputs and outputs of your code Test cases should be written even before the implementation.

Unit test is not really about nding bugs, it’s about designing software components robustly.

2 / 8 4 / 8

HOW TO DO UNIT TESTING?

For each unit (e.g., a method, a class) of your source code, write a test suite that veries that the unit is working as expected. Run the test suite as the unit is being implemented. Run the test suite whenever the unit is changed.

3 / 8 5 / 8

SELECTING TEST CASES

Test for Success:

General cases, well-formatted input, boundary cases Classics (depending on your data): 0,1; odd,even; beginning,“middle”,end

Test for Failure:

Invalid input Does it throw the exceptions it is supposed to?

Test for "Sanity":

Check data structure consistency Consider writing comments (representation invariants) that state what constitutes consistent

3 / 8 6 / 8

DESIGN FOR TESTABILITY

When you are writing code, think about what you need to test and how you can test it. Always write toString() methods for your custom classes (makes debugging so much easier) Write methods that do one single thing Separate input, computation, and output when possible Modularity, modularity, modularity. Don’t delay writing tests! Write tests before you write code as part of the requirements stage and update those tests as or after you write code.

3 / 8 7 / 8

PICKING A VISIBILITY

Choose Java member visibilities carefully Public and protected are both effectively public Private is untestable "package private" can be very helpful when dealing with testing

3 / 8 8 / 8