Writing Test Cases for Web Browsers =================================== This is a guide to making test cases for Web browsers, for example making test cases to show HTML, CSS, SVG, DOM, or JS bugs. There are always exceptions to all the rules when making test cases. The most important thing is to show the bug without distractions. This isn't something that can be done just by following some steps, you have to be intelligent about it. Minimising existing testcases ----------------------------- STEP ONE: FINDING A BUG The first step to making a testcase is finding a bug in the first place. There are four ways of doing this: 1. Letting someone else do it for you: Most of the time, the testcases you write will be for bugs that other people have filed. In those cases, you will typically have a Web page which renders incorrectly, either a demo page or an actual Web site. However, it is also possible that the bug report will have no problem page listed, just a problem description. 2. Alternatively, you can find a bug yourself while browsing the Web. In such cases, you will have a Web site that renders incorrectly. 3. You could also find the bug because one of the existing testcases fails. In this case, you have a Web page that renders incorrectly. 4. Finally, the bug may be hypothetical: you might be writing a test suite for a feature without knowing if the feature is broken or not, with the intention of finding bugs in the implementation of that feature. In this case you do not have a Web page, just an idea of what a problem could be. If you have a Web page showing a problem, move to the next step. Otherwise, you will have to create an initial testcase yourself. This is covered on the section on "Creating testcases from scratch" later. STEP TWO: REMOVING DEPENDENCIES You have a page that renders incorrectly. Make a copy of this page and all the files it uses, and update the links so they all point to the copies you made of the files. Make sure that it still renders incorrectly in the same way -- if it doesn't, find out why not. Make your copy of the original files as close to possible as the original environment, as close as needed to reproduce the bug. For example, instead of loading the files locally, put the files on a remote server and try it from there. Make sure the MIME types are the same if they need to be, etc. Once you have your page and its dependencies all set up and still showing the same problem, embed the dependencies one by one. For example, change markup like this: ...to this: Each time you do this, check that you haven't broken any relative URIs and that the page still shows the problem. If the page stops showing the problem, you either made a mistake when embedding the external files, or you found a bug specifically related to the way that particular file was linked. Move on to the next file. STEP THREE: MAKING THE TEST FILE SMALLER Once you have put as many of the external dependencies into the test file as you can, start cutting the file down. Go to the middle of the file. Delete everything from the middle of the file to the end. (Don't pay attention to whether the file is still valid or not.) Check that the error still occurs. If it doesn't, put that part pack, and remove the top half instead, or a smaller part. Continue in this vein until you have removed almost all the file and are left with 20 or fewer lines of markup, or at least, the smallest amount that you need to reproduce the problem. Now, start being intelligent. Look at the file. Remove bits that clearly will have no effect on the bug. For example if the bug is that the text "investments are good" is red but should be green, replace the text with just "test" and check it is still the wrong colour. Remove any scripts. If the scripts are needed, try doing what the scripts do then removing them -- for example, replace this: ; ..with:

test

...and check that the bug still occurs. Merge any