REF: So you think you write unit tests? Think again

A must! Please don't loose this very brief list of some of the different kinds of tests compiled by Chris Ashto, who is mad about the wrong naming of unit tests. You're right, Cris, often what most people call unit tests are in fact integration tests.

• Unit test: tests a function or class in complete isolation from other code in the system. If the item under test has dependencies, those dependencies are replaced by fake ("mock") objects. If it touches the filesystem, hits a database, access a network, or displays UI, it's not a unit test. Unit tests have practically no setup and run extremely fast.
• Integration test: tests the interaction of two or more classes and functions working together. Multiple layers are usually involved. Whereas unit tests ensure that the "bricks" in your system are square, solid, and uniform, integration tests ensure that they are stacked up correctly and glued together the right way. A test that verifies data entering one end of a pipeline will come out the other end is an integration test. So is a test that verifies that data is unchanged when round-tripped through a reversible process.
• Characterization test: tests unknown or "legacy" code for response to stimuli. Often used during refactoring to ensure that the behavior of the code is unchanged. Characterization tests are often written in total ignorance of the inner workings of the code, and the expected results are often completely unknown as well.
• Developer test: any sort of test (unit test, integration test, acceptance test, stress test) written by a developer as a design and development aid, as opposed to a QA engineer ensuring the correct operation of the code after the it has been "thrown over the wall" to Test.
• Automated UI test: a test that simulates a fixed series of user interactions, such as mouse clicks and key presses, and the resulting UI is then compared to an expected result.
• Regression test: a test which ensures that bugs that get fixed stay fixed.
• Checkin test: a series of tests used to verify that the product is not accidentally broken by new features or bugfixes, prior to the change being submitted. Checkin tests do not exhaustively test everything (they still need to run in a reasonable amount of time), but they should give good coverage over certain areas. Checkin test suites are usually mostly unit tests, because unit tests execute so quickly. But integration tests and regression tests can be good candidates for inclusion as well.