|
Testing Foundations
|
Here are tools I have written that are still publicly available.
StepFixture is what I use instead of the ActionFixture that comes with Fit. Here's a brief sample of what it looks like:
|
A clinician can have the clinic absorb some charges. Perhaps a test was done only for educational purposes, or the animal stayed an extra day.
| |||||||||||||||||||||||||||||||||||||
I offer a zip file that contains both the source and a jar file containing StepFixture plus the standard Fit fixtures. The documentation is in a different place. I also have a series of random notes on using Fit.
GCT was my third coverage tool. It instruments C code in a source-to-source translation, then passes the instrumented code to a compiler. Its first major use was on a Unix kernel, so it is suitable for measuring the coverage of embedded systems. In addition to branch and multiple-condition coverage, it also has boundary-condition and loop coverage. I find those useful and inexpensive types of coverage, and I'm disappointed that more coverage tools don't include them. It also contains a type of coverage we used for evaluating stress testing of a multiprocessor kernel.
However: GCC was written in 1992 using the GNU C compiler (gcc) as a base. For reasons too boring to explain, it still has most of the original GCC code in it. The practical effect of that is that porting GCT is not as trivial as it should be. Although there are Linux and Solaris ports, I do not have appropriate configuration files for them. (If you do, please send them to me.) There are no ports to any version of Windows or other non-Unix operating systems. I would be stunned to see one.
Since GCT is based on gcc 1.x, it does not handle some gcc 2.x constructs. There has been a mostly-completed port from gcc 1.x to 2.x, but I have not used it myself.
GCC has no GUI for looking at coverage results. The output is formatted like error messages from a compiler. It comes with an Emacs mode (based on M-x next-error) that I rather liked. But non-Emacs users are left out in the cold - as they are in so many things. :)
For more about GCT, I recommend "A tutorial introduction to GCT". "Experience with the cost of different coverage goals for testing" describes the way I used GCT back when I programmed in C. As someone who's written four coverage tools, I rather like them. However, they're often misused. See "How to misuse code coverage". Coverage terminology is unnecessarily confusing, so I wrote "A buyer's guide to code coverage terminology".
The complete source and documentation (postscript) for GCT 1.4 can be found here. Please look at the README file first.
The source for GCT2.0Beta can be found here.
There are no precompiled executables.
Trace.java is a fairly featureful tracing system for Java. It was developed for a company that no longer exists, which fortunately released it under the Mozilla license before vanishing.
To use it, programmers scatter tracing statements throughout their code. Tracing statements can be associated with particular classes or arbitrary strings. (Most usually, the string names some meaningful subsystem of the program.) Tracing statements can be at different levels, such as error, warning, debug, and so forth. Trace statements are logged only if the level is above some threshold. The threshold may be per-class, per-subsystem, or system-wide. Thresholds can be set at program launch time and changed at runtime. Trace statements can be logged to either an in-core buffer or to disk or both. When logging to both, it's typical to set the threshold of the in-core buffer low, so it captures more messages. Because the buffer has a fixed size, most messages are invisibly discarded - except when you encounter a bug, whereupon you examine the last N messages. The disk log can either grow indefinitely or have a fixed size.
About the only thing that's obviously missing is the ability to have different logs for different subsystems.
The documentation is here.
The source and a jar file are here.
This started out as a rewrite of the Java tracing package in the Ruby language, but rapidly evolved in its own direction. Look here.
A test idea is a brief statement of something that should be tested. For example, if you're testing a square root function, one idea for a test would be "test a number less than zero". The idea is to check if the code handles an error case. Multi suggests test ideas for mixed boolean and relational expressions. Like this:
% multi
Type in an expression.
'q' to quit.
> a && b < c
Test ideas for (a && (b<c)):
a (b<c)
----- ------------
true b barely < c
FALSE true
true b==c
> q
Look here for more.