Writing Bad Test Cases

So, you spend days and days writing test cases and you find out that they become more of a hassle than you expected. Here are some common mistakes in writing test cases which may help you in your test case development.

1) Your test case creates live data. When you do a quick test case to try to make sure your function works, sometimes you simply set it up to create a new record in your database. This can happen in several ways.

• You connect to a Live API with your test case. This could actually send credit card transactions, or send live records to your other application, which dilutes live data with fake records. This could lead to bad reporting in the long run.
• You connect to your live database to test your functions. This is a really bad idea. Make sure your connection string points to a test database or you may end up losing mission-critical data.

2) You change your code to accommodate for test cases. This is a mistake as well. Your code should do what it was intended to do. If you need to add debug lines or incorporate new functionality into your code so that test cases will work, then chances are you either need to go back and study up on test case development or you need to redesign your code so that test cases will not interfere with the system process.

3) You make test cases depend on each other. This is a temptation that should be avoided. When you are running test cases, each function should be independent, even though test cases run linearly. You should not have one test function that presets data, and then assume that that function was called by the test suite.

For instance, let's say I have a test called testLoadUserData and that function loads user information into the variable $this->userdata for testing. Then under than I have a test for testShowUserData. It would be a mistake to assume that $this->userdata still exists in testShowUserData. Why? Because sometimes we comment out tests so the page doesn't take so long to load. This could breat testShowUserData if it depends on other tests. A better solution would be to write a loadVariables function and call it in each test case.

The goal of test cases is to help write modular functions. Often times poorly designed code will cause problems in developing test cases. If you write bad test cases, just consider it a learning experience, and keep at it until it works well.

Good code is poetic in nature.