More Criteria and Techniques for Good Tests

Whitebox Testing
1.0x

More Criteria and Techniques for Good Tests

Created 3 years ago

Duration 0:03:30
lesson view count 216
Select the file type you wish to download
Slide Content
  1. More Criteria and Techniques for Good Tests

    Slide 1 - More Criteria and Techniques for Good Tests

    • Emerson Murphy-Hill
    • Creative Commons Attribution 4.0 License.
    • Material Produced by NCSU Software Engineering Faculty.
  2. Other Criteria for Good Tests

    Slide 2 - Other Criteria for Good Tests

    • Concise – Tests are as simple as possible.
    • Self Checking – Test should report its results such that no human interpretation is necessary
    • Repeatable – Test can be run repeatedly without human intervention
    • Robust – Test produces the same result now and forever. Tests are not affected by changes in the external environment.
    • Sufficient – Tests verify all the requirements of the software being tested.
    • Necessary – Everything in each test contributes to the specification of desired behavior.
    • Clear – Every statement is easy to understand.
    • Efficient – Tests run in a reasonable amount of time.
    • Specific – Each test failure points to a specific piece of broken functionality – one possible point of failure
    • Independent – Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.
    • Maintainable – Tests should be easy to modify and extend
    • Traceable – Tests should be traceable to the requirements; requirements should be traceable to the tests.
  3. Build scaffolding for incomplete code

    Slide 3 - Build scaffolding for incomplete code

    • Stubs and drivers are code that are (temporarily) written in order to unit test a program
    • Driver is a software module used to invoke a module under test and often, provide test inputs, controls, and monitor execution and report test results
    • main() {
    • countDigits(“2 5 7”, 3, 9);
    • }
    • Stub is a module that simulates components that aren’t written yet, formally defined as a computer program statement substituting for the body of a software module that is or will be defined elsewhere
    • public void movePlayer(Player player, int value) {
    • player.setPosition(1);
    • }
  4. Test Driven Development (TDD)

    Slide 4 - Test Driven Development (TDD)

    • Write an automated unit test
    • Run tests to ensure they fail
    • Implement code to pass the test
    • Re-run tests to ensure they pass
    • Restructure the production and test code, as necessary
    • Run better
    • Better design