This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Types of tests Feed Title: Jared's Weblog Feed URL: http://www.jaredrichardson.net/blog/index.rss Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers. Latest Agile Buzz Posts Latest Agile Buzz Posts by Jared Richardson Latest Posts From Jared's Weblog

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