Some people talk about automatically generating test
case classes from an implementation. But how useful is
that, really? I mean, you can't easily discern what
tests to run, so all you are doing is writing a bit of
simple boilerplate.
What would be really useful is a tool that encouraged
the XP-style "write the tests first" methodology.
Here's how it would work:
1) User writes the new test case, assuming that any new
classes and/or methods that will be implemented exist
already. This means the test class will reference
methods, fields or classes that don't exist yet.
2) User runs stub generator. It examines the test case
and finds methods, fields and classes that don't yet
exist (possibly prompting the user to disambiguate some
of them, although I'm not sure), and then generates the
code as needed to fit the signatures required in the
tests. (It implements all methods by throwing
NotImplementedException.)
The goal is that after this, the new test case will
compile, and all the test cases will fail.
3) Note that the stub may have to make up default
answers sometimes for things not knowable from the test
cases, like the return type of methods might sometimes
be guessed as "Object" or something when the user
wanted something more specific. (This would happen if
the test didn't clearly show the return type of the
given method.) Thus, the user might have to refine the
signatures of the generated class(es).
4) The user modifies the generated class to implement
the methods.
5) User runs test cases, and goto 4 unless they all pass!
Now wouldn't this be cool?
Logged In: YES
user_id=429731
This definitely has value for encouraging testing first, but
I claim the opposite also has significant value for
beginning students-- see feature request 592214 (Generate
Test Case from Class).