My Critique of this program at this stage in it's life.
This program is incomplete in a few areas.
Some are intentional omissions (for this version at least), and others are 'kinks' I
know will come out when I refactor. But, I did want to list them, in case you were
wondering.
You may have noticed that you cannot delete anything. This is intentional for now.
Too much work goes into creating tests to risk inadvertent deletion.
You can place the statement 'RETURN' at the beginning of the test code, to bypass the test,
or delete the test code entirely.
Experiments that where used interactively, and contain tests that do not seem necessary,
or they contain intermediate code placements (e.g. classes defined in test code, but later moved to prg.),
are often thought of as 'wasted space', a burden on full regression testing, and are the usual
candidates for deletion. However, I feel that keeping all of the intermediate work can be very useful,
for Refactoring and understanding the thinking that went into creating a component.
I felt that these benefits out-weight the decreased overhead and improved performance, and so, no deletion.
You can enter a class and method name, but cannot edit them. This just missed this version.
The goal for this is to offer a list of classes and their methods contained in the source file.
At the same time, it should be easy to enter class and method names that do not yet exist in the source file.
(in the spirit of test-first design, where the class names do not exist at first)
Maintenance screens for some of the lab components are missing.
(e.g. no screen for renaming a Suite, nor for merging, or splitting a suite).
The edit windows are flaky. I'm expecting that to improve with Refactoring.
It is possible to drag commands from the Fixture 'statements' window, onto the
test code edit window, and test 'statements' onto the fixture edit window.
The commands may be inappropriate in the wrong context, and strange exceptions may occur,
unrelated to the user code. It is relatively straightforward on how to handle some of the
effects, but is proving harder to prevent. The editboxes will not allow a drop from the
inappropriate 'statements' window, but the edit windows are a different story.
In fact, you can drop just about any text in an edit window, which is great for running the example code
you find around the net (exceptions will be trapped in the results, which is useful when trying to get them to work),
but is also risky, for there is little control over what will be executed from a code window.
'Revert' after a 'New' experiment, leaves a blank experiment. It should display the last experiment
prior to the 'new'.
Only one experiment may be open at a time.
No printable output available.
Results are not persistent between sessions.
There is a slight, but real, possibility of name collisions. If a user defined class name happens
to be the same as a lab class name, erratic exceptions could result.
Temporary files may not be deleted in some circumstances. If an object cannot be released after
an experiment is run, and it is defined in a temporary file, assembled from user code in the test code
or fixture, the temporary file created to define the class cannot be deleted.
This is a really only a problem when public variables are used.
IF there is a class definition in the test code or fixture, and an object is created from that definition
and assigned to a public variable, the public variable will keep the object from releasing,
and an exception will occur because the file cannot be deleted, there is a class in use.
There are a few other cases, but they all seem to be related to keeping an object 'alive' outside
the scope of the program defining it. Another possible scenario is where an object is defined and
created in the test code, and then assigned to a fixture property. If that fixture property is not
set to "blank" (null, .F., "", ..,), the fixture will 'hold the object up', outside the lifetime of the
test code {sampleing).
Handling the effects of this problem is relatively straight forward, in that the file names
that could not be deleted, could be stored, and then deleted at some later date.
(this solution will be used in the next version)
More/Better test results info. Include things like: the suite name running (if any),
line position in original source code, better messages for errors/exceptions, possibly a tie-in to a
help database that could offer explanations for a particular error/exception, ..,
| |