No matter how you slice it, software development is tricky business. A majority of problems can usually be solved by isoloating your problem in a few lines of code. Secondly, well written test case can help others make sense of what you are trying to do. There are not hard and fast rules as to what makes a good testcase, but the following guidelines should be kept in mind.
Often times people jump into IRC asking for help. Usually they post 300+ lines of code to a pastebin, get no response then rage quit. Most people fail to realize is that even the most experienced and seasoned software engineers will need to sit down for a minute or two to figure out what’s going on. Most people on forums or chats are simply unwilling to do so, because their time is valuable and they’re certainly not going to bend over backwards sifting through somebody else’s code to figure out what’s going on…unless they’re getting paid to do so, of course.
- Stick to only standard language features. The core language features are extremely well tested and documented. Isolating your problem to only standard features virtually eliminates the possibility that the problem you’re encountering is the fault of third party code. That is not to say that all language implementations are perfect, often times implementation bugs are discovered through simple and isolated test cases.
- Keep it concise. You are trying to solve only one problem at a time. Usually a good testcase involves a single class or function demonstrating the problem. Create mock objects where necessary to use in place of more complicated objects.
- Post the actual results, expected results, and how they differ. This helps anybody reading your code the opportunity to pinpoint the particular problem. For instance a VB programmer may attempt to use something like 2^3 to represent pow(2,3) in C. A proper testcase would contain a the comment, “I’m trying to calculate two raised to the third power, but this program just prints ‘1′, I should see 6.” Followed by a snippet of code you could feed into any c-compiler that would demonstrate the problem.
- Avoid any random, unpredictable, or undefined behavior. Random results are difficult to interpret. Often times code relying on undefined or indeterminate behavior may work fine on some boxes but not on others. It is possible to post code that crashes for you, and works fine for everybody else.
-
The code should be a complete program. A complete program should compile and run. If you’re trying to solve a particular compiler error, try to write code that produces just that compile error and nothing else. It’s usually easy to explain a single compile error with a little bit of context than it is to muddle through dozens of errors. Don’t assume that somebody understands some framework you’re using. Once again, even seasoned software veterans need to study an unfamiliar base of code before knowing how it applies to your problem.
If you learn to write test cases well, you can better communicate your coding problems to others wheather they be bosses, coworkers, or random people on chats/forums. You also will force yourself to write stable and maintainable code, and will likely learn a thing or do doing it and won’t have to rely on others nearly as often to accomplish what you want effeciently and effectively.
