Post on 03-Jan-2016
Testing Large Systems
• Old school:– Programmers write parts of code• Maybe check tricky bits
– Someone tries to build whole project• Sort out incompatibilities
– Hand it off to testing• This job is awful
Testing Goals
• Principles:– Tests should cover as much code as possible– Tests should be run after any significant change– Tests should not clutter up core source
Testing Goals
• Principles:– Tests should cover as much code as possible– Tests should be run after any significant change– Tests should not clutter up core source
• So:– Tests better be easy to write– Tests better be easy to run– Tests better exist outside normal structure
Doing Unit Testing
• Basic idea:– Write functions TESTS to test your code• Tests can be passed or failed
What does it actually look like?
• Base project– Normal application– Header file(s) for classes– .cpp file(s) for classes– main file with "real" program
What does it actually look like?
• Test project– Special header with test stuff• Included in test files only
– One .cpp file to test each class – New main file to run tests
Details
• CLASSXTESTER.cpp– Includes class.h / catch.hpp– Has TEST_CASEs
Expression that must be true
Machine name - must be unique Description
Details
• CLASSXTESTER.cpp– Includes class.h / catch.hpp– Has TEST_CASEs
Expression that must be true
Machine name - must be unique Description
Details
• Pattern– Make an object– Call functions to be tested– REQUIRE correct data• Must use public methods to access
What Do I Test
• Test public interface• Test every method/construct except…– Trivial one liners:• Usually don't directly test getXXX()
– IO code:• Hard to do from testing frameworks