Main Page - Books - Links - Resources - About - Contact Me - RSS

Most Popular Help! I've Inherited Legacy Code Testing Untestable Code Continuous Integration... Why Bother? Mock Client Testing The Art of Work Technical Idiot Savants Targetted Skills Aquition vs Free Range Chickens The Habits of Highly Effective Developers

Blog Archive 2005-December 2005-November 2005-October 2005-September 2005-August 2005-July 2005-June

Wed, 24 Aug 2005

Types of tests

Jeffery Fredrick posted a great blog entry on a comment by Michael Feathers called Rules for Unit Tests. It's a great set of litmus tests you can apply to your so-called unit tests and see if they really are unit tests.

So what other types of tests are there? I'm glad you asked! ;)

Taken from Ship It!, pages 43 and 44.

There are many different kinds of testing; each one is targeted at identifying a different kind of problem.

Unit tests are designed to test your individual class or object. They are stand-alone, and generally require no other classes or objects to run. Their sole purpose in life is to validate the proper operation of the logic within a single unit of code.

Functional tests are written to test your entire product's proper operation (or function). These tests can address your entire product or a major subsystem within a product. They test many objects within the system.

Performance tests measure how fast your product (or a critical subsystem) can run. Without these tests, you can't tell whether a code change has improved or degraded your product's response time (unless you are really good with a stopwatch!).

Load tests simulate how your product would perform with a large load on it, either from a large number of clients or from a set of power users (or both!). Again, without this type of test, you can't objectively tell if your code base has been improved or degraded.

Smoke tests are lightweight tests and must be carefully written to exercise key portions of your product. You would use smoke tests because they run fast but still exercise a relevant portion of your product. The basic idea is to run your product to see if it "smokes," i.e., fails when you invoke basic functions. Smoke tests are very good to use with your Continuous Integration system (see Practice 4, Build Automatically, on page 30) because they're fast. During your product's life cycle, the smoke tests that you actively run will probably rotate. Your smoke test suite targets areas of active development or known bugs.

Integration tests look at how the various pieces of your product lines work together. They can span many products: sometimes your products and sometimes the third-party products you use. For instance, various databases used by your product can be exercised as part of your integration tests. You want these tests to cross product boundaries. Integration tests are often used to validate new versions of the components your product depends on, such as databases. If a new version of your favorite database comes out, you will want to know if your product can run with it. A suite of tests that exercise functionality all the way down to the database should answer the question of functionality for you and also give you a quick look at your performance with the new components.

Mock client testing is used to create tests from your client's point of view. A mock client test tries to reproduce common usage scenarios for your product, ensuring that the product meets minimum functional specifications. This type of testing can be very effective for getting essential testing coverage in place to cover the most commonly used code paths.

So what's the best and most important type of test? The type that are run frequently!

Enjoy!

Jared

posted at: 22:19 | path: | permanent link to this entry