Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

23 Cards in this Set

  • Front
  • Back


the principal activity for verifying and validating software

types of testing:

- prototyping

- iterative approaches

- frameworks such as the Dynamic System Development Method (DSDM) which documents best practice processes for iterative and incremental development

unit testing

- usually performed on classes, with the focus on the systematic testing of methods using test cases

- the most common tool is JUnit integrated into Java IDEs

- similar frameworks called xUnit


- provides a framework that makes it easy to write and manage tests using a standard format

- provides a special test class, and automatically subclasses it for each class to be tested

- testing a class it automatically creates an empty class

- you then populate the test class with a series of test methods, usually one test case for each method

- it is automatically executes and manages the test methods

- each time the test run it generates a report listing that itemises which tests the software passed and which failed

Test-Driven Development TDD

- code is written in very small increments usually 5-10 lines of code

- but before the code is written a test case is written

process of TDD

- decide on a code increment

-decide on a test

- write the test

- run all tests , expecting the new one to fail

- write the code: don't add any extra functionality, only the minimal to pass the test

- run all the tests and succeed

benefits of TDD

- test coverage

- regression testing and early discovery of errors

- executable documentation

- beneficial effect on design

- complementary with DbC

- promotes good code quality

- inhibition of featuritis

test covarage

the finished code already has an extensive test suite

regression testing and early discovery of errors

changes that break tests can be quickly identified and rectified

executable documentation

the tests both shows how the code should be used and indicate what it should do by means of test cases

beneficial effect on design

the writing of tests contribute to design as well as testing.

- TDD encourages clarity, modularity and a focus on interface over implementation

complementary with DbC

TDD tests with test cases while DbC tests by invariants. therefore they are complemetary

promotes good code quality

focuses on quality, design for testability and early and frequent refactoring

inhibition of featuritis

because addition of extraneous code is discouraged during TDD cycles, creeping featuritis - the addition of unnecessary features is inhibited

limiations of TDD

- user interface

- testing for aplication integrated with databases

- multithreaded systems

- customer acceptance

- legacy systems and systems reusing large code components

- management support

- code whose requirements are liable to change greatly

- integration testing

- TDD is only as good as the test devised

user interface

TDD does not apply to user interface testing

testing for applications integrated with databases

TDD alone is not adequate for the comprehensive testing of databases

multithreaded systems

TDD is not generally suitable for the esting of multithreaded systems

customer acceptance

TDD cannot take the place of customer testing

legacy systems and systems reusign large code components

if TDD was not applied and large amount of code was used then at best unit tests must be aded retrospectively

management support

if management choose to penalise time spent on writing tests during development, TDD is unlikely to flourish

code whose requirements are liable to change greatly

in exploratory programming ( where requirements are not sure) TDD cannot be used

integration testing

TDD cannot take the place of integration testing

TDD is as good as the test devised

devising good tests and effective test cases is as important art and one that applies with a scope for beyond TDD