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
- WebKit on Test Case Reduction
- CodePen is a good app for creating reduced test cases.
Know of any other good discussions on this topic? Let me know I’ll link them up.
I agree.
While I’m typically not working with a webpage when I submit a but report, I almost always produce a snippet of code that reproduces the bug with as little extra information as possible. This means even reducing the complexity of documents that go with the bug, if possible. It’s the same thing I’d do for webpage-based bug reports.
I should also note that because of this tactic, I typically get very helpful responses, and I get them quickly.
Definitely. The idea of RTC’s transcends the web for sure, into just about anything where something can go wrong.
Definitely agree. I do this frequently when I’m on CMS builds where I’m already in the data-driven stage but have front-end issues down the line. If I can make a static example of something its much easier to debug. For CSS position/dimension issues I love to use ridiculous background colors on elements, like Red, Lime, Fuscia, etc. The bg color makes elements easy to see and doesn’t add to their size like borders. If its JS, console.log() and alert() are key.
Definitely agree. I do this frequently when I’m on CMS builds where I’m already in the data-driven stage but have front-end issues down the line. If I can make a static example of something its much easier to debug. For CSS position/dimension issues I love to use ridiculous background colors on elements, like Red, Lime, Fuscia, etc. The bg color makes elements easy to see and doesn’t add to their size like borders. If its JS, console.log() and alert() are key.
+1
On some forums I follow it’s very common for people to post long code examples, but as WC points out, they rarely get helped. It just takes to much time to check out all the code.
It’s usually the beginners who post long parts of code (or even entire pages). Can’t blame them because it’s probably something DreamWeaver generated and they have no clue what any of the code means.
with beginners, it’s best that way – by reducing the code they provide to the part they think is problematic, they usually exclude the problem.
Either that, or they “theorize” the problem to the point that you can’t even figure out what their question is.
If I’m going to help them, I’d rather wade through their entire code and find the problem myself. Otherwise, it’s just a blind guess.
Thanks for the great info. I ran into a trouble problem just a few days ago, and this would have helped out greatly, as I had that glazed over look trying to find the issue!
This is a great article. Sometimes, depending on the situation, if I have a certain section of code that I think will be a little tricky, I will build it and get it working independently and then integrate it into my project. This helps cut down on troubleshooting in my experience.
great recommendations.
I do something kind of similar when facing CSS browser issues. I’ll start with the top most container and display:none it. If the bug goes away I know it’s contained somewhere in that container. I then go down, layer by layer, displaying none until I find what’s actually causing the problem. I’m normally able to fix crazy bugs in 5 minutes or less doing this :)
Yes, CSS isn’t doing what I think it should, especially at IE6. I use “float:left” or “clear:both” to do it. It is really a good method to use dropbox to put it online. But people from China can’t visit dropbox directly, just like blogger, twitter, facebook.
Great point. I’ve been thinking how to put this same thing.
When I get a really hairy coding thing, in the end, I get HUGE gains, by taking the time to break it out into a VERY simple little test.html, test.js type of thing … and drill down to the EXACT issue, in a very bare bones, stripped down way.
I see newer coders not get this. They get lost … they get confused. The biggest issue is “not go get lost down the rabbit hole”. If you can do that, you’re okay.
Code is really complicated, even if you think you’re a genius. If you reduce the overall cognitive load, it’s going to go remarkably faster.
This is the best approach to problems. I couldn’t agree more.
You can get a whole new look to the problem and even make it better than originally conceived.
Very good advice! I myself been doing this for years without ever thinking about sharing this tip…
This is the kind of advice that is missing on the Web : how to catch a fish. Stop giving fishes away!
Good tip(s). And 1000 lines of CSS posted into a forum? Yikes! At least CSS is dirt-easy. 1000 lines of Perl in a forum might scare me, but anyone wanting help finding one bug should never post that much of anything!
very nice tips thanks lot
excellent article, thanks for sharing, good work.
I do the same thing!
I just copy the page, remove the unnecessary code and give it an obvious ‘test’ name like index_test.php so I know to delete it afterwards.
This is excellent advice. I’d be surprised if anyone learning to code hasn’t used this method pretty frequently.
I’d never put a name to it before though. Sounds so much better explaining that there is an issue and you are working on a reduced test case to solve the problem.
Thanks for the terminology!
awesome post. thanks a lot buddy
This is usually a good advice for many types of coding not only web programming.
A slight variant on this approach is to use something like jsFiddle. It has separate text boxes for your javascript, css and html. If you can reproduce the problem in there, then you can very easily make changes and update them, and you can share your fiddles with others.
As well as the CSS-tricks forum, there’s also Stack Overflow and doctype for getting quick answers to your problems…
Great advice, rarely go to forums for help but this is a technique we use a lot when doing back-end dev work. Much easier to spot an error in one or two lines than 20.
Thanks for the checklist!
good, it is useful for me ,thanks