Reduced Test Cases

Avatar of Chris Coyier
Chris Coyier on (Updated on )

If you are having trouble with something while building a webpage, the most helpful thing you can possibly do is start building a reduced test case. “Trouble” could be anything: the CSS isn’t doing what you think it should, the JavaScript isn’t behaving right, there are cross-browser issues, etc. In the process of creating a reduced test case, you will either:

  • Find out it was a mistake you made, help you isolate it, and fix it (or have a great test page for asking for help)
  • Discover a true bug, and arm you with the perfect demo to present to the people responsible.

So what is a reduced test case, anyway? A reduced test case is a demo/example page you create which reproduces the problem you are having with the least amount of code possible. Only the HTML needed to show the problem content. Only CSS that is related to that reduced HTML. Only the JavaScript related to the problem functionality at hand.

Reduced test cases are the absolute, no doubt about it, number one way to troubleshoot bugs. In fact, some people contribute to open source projects simply by turning bug reports into reduced test cases for more experienced developers to explore. Here is how you might get started creating one from your problems…

1. Make it static

If it’s a front-end issue, make the page static instead of dynamically built from the server (like if you are using a CMS of some kind). That is, view the source on the problem page, copy and paste it into a new document, and start there with your reduced test case. Put that document into a new directory just for your test case.

2. Make it isolated

Then take all the resource files that HTML needs (CSS, images, JavaScript, etc) and put them in that directory too. Now you have a contained little environment just for this purpose. Now you can edit these resource files and markup without worrying about affecting anything live. This also makes your test case portable should you need to hand it off to someone.

3. Reduce, reduce, reduce!

Now start stripping stuff away, periodically testing to make sure your problem is still present. Start by removing HTML so what is visible on the page is reduced down to as little as needed. Then remove any CSS that is now un-needed. Then remove any JavaScript that isn’t related to the problem. If it’s not a JavaScript problem, remove all of it (unless you think it may be JavaScript interfering with whatever the problem really is).

4. Document it

If there are bits in the code that you suspect may be the problem, put comments in the code there. Every single web language has some way to insert comments that don’t affect the code.

5. Put it online

If you are working locally, put up your reduced test case online somewhere. I’ve seen people use the free Dropbox to host a quick example. This will make it easier for you to share the problem with others who may be able to help out.

But I don’t know what the problem is! They need to see everything!

You do know what the problem is. It is whatever the problem is. Showing someone “everything” is often overwhelming to them and makes it harder for them to get their heads around. That’s how I feel, anyway. If someone is asking for help and they paste 1000 lines of CSS code in the forums, my eyes usually glaze over and I just skip it. A reduced test case however, is often intriguing and begs to be looked at.

Other Resources

Know of any other good discussions on this topic? Let me know I’ll link them up.