--- In uispec4j@yahoogroups.com, "Regis Medina" <regis.medina@d...> wrote:
> Hi Nascif,
>
> > Problem solved - and I tracked it down to how I defined my testcase
> > constructor [...]
>
> That was tricky, the JUnit message could have been more explicit.
Maybe we
> should tell them about this issue, or suggest a patch? Do you know
were in
> JUnit the assertion error is raised?

Sure. The code that creates the problem is this one, from TestSuite.java:
static public Test createTest(Class theClass, String name) {
Constructor constructor;
try {
constructor= getTestConstructor(theClass);
} catch (NoSuchMethodException e) {
return warning("Class "+theClass.getName()+" has no public
constructor TestCase(String name) or TestCase()");
}
Object test;
try {
if (constructor.getParameterTypes().length == 0) {
test= constructor.newInstance(new Object[0]);
if (test instanceof TestCase)
((TestCase) test).setName(name); <<<<
} else {

Note how it never checks if name is valid (not null).
Then later the assertion that fails is this one from TestCase.java
protected void runTest() throws Throwable {
assertNotNull(fName); <<<

A patch to fix that would be quite simple:
1) adding a message to the assert in TestCase;
2) adding an assert (with a message!) to the call in TestSuite

I learned something interesting from this experiment: JUnit creates a
new instance of your testcase class for *each* test method! I guess
this helps ensuring that there is no shared content between tests, but
it was a surprise to me.

> I agree with you that the constructor approach may lead too
frequently to
> this issue, so we will add a setAdapter() as you suggest in release
0.12.
> This setAdapter() could be called from within setUp(), we only need
it on
> a first call to getWindow().

Thanks, I will be looking forward to it.

....
> That's great news! Please do not hesitate to contact us again if you
have
> any suggestion for improving UISpec4J.

Well, I do have another one :-)

I have not used the Extension mechanism, just read about it. Use use
of byte-code extension is very slick, made me think of a customized
application of Aspects. Yet I think it might be a problem concerning
the integration of the tool with the rest of my environment. It will
make it hard to upgrade to new versions of UISpec4J, since it will
force me generate and push to the source code repository a new version
of the jar; it also makes it harder for projects accross the company
to share the library as it one has to have its own modified version
with its own extensions. The alternative is to "recompile" the library
with my own extensions as part of the build, but that adds more
complexity to it. It is feasible, but a little too complex for what
the extension does.

My point is, think about the tool not as a one-time thing, but as part
of a cycle that has to be repeated many times, maintained and shared
across groups.

What about using a configuration file instead? Instead (or in addition
to) using reflection to keep track of "markers" on the class files at
run time, you could just read the former ExtensionGenerator arguments
from a config file, provided as an argument in a system property. This
would be much simpler to track and maintain over the life of a
project, and would allow multiple projects to share the same .jar and
just use their own config files.

Then again, I don't know enough about the Extension mechanism to know
if this proposal even makes sense. What do you think?

Regards,
Nascif