This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Mock Client Testing 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

What is Mock Client Testing? I think it's the best way to get good coverage on a legacy product or an existing code base. It's also a great way to test on your new code.

First, let's talk about unit tests. By definition, one test involves one unit, usually a single class. They are fast and generally stand alone. They are written to ensure that a given class or object (a unit) works properly.

However, in the context of a larger software program, what does a unit test really tell you? Well, it enforces the social contract that tells you a class does what you expect it to do... or more accurately, it tells you that class does what the writer and test writer intended for it to do. The test doesn't tell you if the class interacts well with your code or if it's doing what you need done.

Don't get me wrong, unit tests are very useful and valuable tools, but often we stop at unit tests. Mock Client tests sit a level above unit tests.

Here's a short description of Mock Client Tests from a sidebar in my recent book Ship it! A Practical Guide to Successful Software Projects

Consider how your product will be used. It can be used by client applications (if you're developing a product) or by lower-level code (if you're writing an API). Write a test suite that emulates the client's behavior. A mock client test uses your product (or a subsystem) just like a normal client would. You have mocked up a client, just like a Mock Object imitates a server or application resource. These are usually categorized as integration tests because they can be run against live systems.

They can be chained together into performance and load tests, or individually they can be used as smoke tests. The concept is quite flexible and powerful! If you have a set of user scenarios, you can put them into a Mock Client Test and verify that they run (and continue to run after you refactor the code base!).

I used the Mock Client Test concept at a biotech company. We created a suite of JUnit tests that exercised most of the functionality in our client program. When a bug made it into the product, we found a way to expose it with an extra Mock Client Test. Before long, the product was rock solid thanks to the test suite and our Continuous Integration system, of course!

We were forced to rewrite key portions of the server code when performance became an issue. Unit tests wouldn't have been useful because many of the classes were eliminated. However, our Mock Client Test suite worked great. The APIs called by the client code didn't change, so the tests could still be run. We used these tests to tell us when the refactored program didn't return the same information as the original program.

In the first test run after the refactoring, our tests caught seventeen bugs. We cleaned those up and then the tests caught twelve. Then five. Then none. The new code went into the field and didn't have a single customer reported defect. We did addtional testing before we shipped, but in this case the Mock Client Tests gave us the information and coverage we needed!

The code wasn't perfect, but the most important parts of the code were clean. The parts that the customer runs is the only code that matters anyway, right?