Developer tests:
Unit tests : Isolated, atomic, innocuous: exercised with xUnit often in combination with mocks objects
=> useful to improve code quality with continuous design
Integration tests:
Isolated tests that might change the state of the system, i.e: saving into database, writing file... An integration test does not represent a functional requirement as is. Can be written for xUnit. They check the integration of our code with a third party tool or with the different layers of our own code, i.e: the business logic layer requires the data access layer
=> useful to reduce the number of bugs per LOC
Functional tests: (also known as System tests)
A test that excercises part of the system as a whole, some functional requirement. It might change the status of the system. Can be written with FitNess.
=> useful to reduce the number of bugs per LOC
Product Owner tests:
Acceptance tests: Functional tests which input and output can be validated by a non-technical person, the product owner. Can be written with FitNess.
=> useful to specify requirements
Source: Categorizing Tests
2 more definitions:
Characterization tests:
A test written to document the current behavior of a piece of software and preserve it as you change its code. Commonly used before changing legacy code. Read Working Effectively with Legacy Code By Michael C. Feathers.
Exploratory Testing:
Exploratory testing is simultaneous learning, test design, and test execution. Commonly used in Agile teams to learn quickly 3rd party library/components/external systems. Read Exploratory Testing Explained, James Bach
Finally some terms from unit testing:
Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes:
- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
- Mocks objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
- Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
- Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
Classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.
Vs
Mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.
Source: Mocks Aren't Stubs, Martin Fowler
Update Dic 2009: see also Visualising Test Terminology