CS190 Testing Standards

Purpose

In a group project, a single bug can hold up the entire group for half a day. This document is intended to give TheFORCE procedures for ensuring that buggy code is not introduced into the source tree. It is important in a group of this size to debug earlier, not later.

Continue to use your usual testing methods, but also use the ones mentioned here.

Disclaimer: this document is not static. Please contact me if you want to suggest any changes or additions.

Test programs

Where applicable, make test programs for your code. Also, combining small test programs into larger, interactive programs can be useful for testing entire pieces.

Where applicable, make test programs for other people's code. This ensures that others' code behaves as you expect it should.

Stepping through code

Review Writing Solid Code chapter 4. Use the suggested testing procedure on any complicated code; don't bother with obvious code unless you feel it is necessary.

Code review/cooperative debugging

Have someone else look over your code. Think of it as a free set of eyeballs to help you debug. It is not necessary to do this formally; don't make appointments for code reviews. Try to work in pairs or groups, and just ask someone to look at what you're up to at an opportune moment. (e.g. when xwrits pops up)

Be attentive and ask questions when reviewing someone else's code.

No memory leaks

Try not to check in code that leaks memory. It is easy to use dbx to find memory leaks for you; use the "check -leaks" command before you run. The "bcheck" program does pretty much the same thing. Talk to me if you don't know how to do this.

Documentation review

When a piece has been finished, review your header comments with someone that needs to use it. The reviewer should ask questions about any ambiguities not documented. This should augment header comments until the piece is completely usable by only reading the header.

UI Testing

(GUI modules only) Test the interface with someone else in the group. Ideally, you shouldn't need to tell them how to use it; they should be able to figure that out by looking. Regardless, get feedback on how the interface looks and behaves.

Keith Dreibelbis

Last modified: Mon Mar 29 00:04:39 EST 1999