#59 Test case naming convention

[Vera Henneberger]

(Comment from the blog)

We have a case that MoreUnit cannot handle. Our class under test might be called "MyClassImpl" to differentiate it from "MyClass" interface, however the test is called "MyClassTest".
I'm thinking there may be no easy fix for this except manually entering the relationship between the package under test and it's test package.
Even the smart lookup doesn't work for this--it finds the interface method instead of the implementation method.
If there is any way to fix this in the current version, please let me know!

[Nicolas Demengel]

Considering the many problems we have with classes/tests relationships, I do think that we should write a new matching system from scratch. Instead of trying to make smart guesses that might eventually not be so smart, I would propose to provide very simple (but sensible) defaults, and then allow the user to finely tune the settings for his needs via an UI that would show him "live" what the result of his settings would be.

[Anonymous]

I keep wishing that the "Jump" hotkey would allow selecting a new test case (or if jumping from the case, select the source file). At that point the directory-directory relationship could be persisted as well as the file-file and test-source to make it easier to match the next one (which would most likely simply pull up a list of methods by defaulting to the correct file).

This could also handle the case where multiple tests test the same method.

[Vera Henneberger]

Yes the current matching system would need some improvements. Showing "live" what the change of a setting results in is a good idea. At the moment users need to take a look at the documentation section on the homepage to get an explanation for each setting.
Rewriting the matching system from scratch might be a very big change in the code base, so we should take a closer look at it. The current implementation has been "growing" for a long time now with more and more features and might contain some code smells now.

[Vera Henneberger]

Another comment from the blog:

Stéphan Mestach hat gesagt...

most of our project are structure like this
* module_api : interfaces, value objects,exception
src/com.project.MyService
* module_impl : implementation
src/com.project.impl.MyServiceImpl
test/com.project.MyServiceTest that relies on MyService and spring runner

with the extended search mode, do you plan to lookup from the interface for MyServiceTest and not from the MyServiceImplTest

[Nicolas Demengel]

We rewrote the matching system (at least the part in charge of class names), and it is now more powerful. But do not implement all the features proposed in this ticket. Maybe we should split it in several other tickets.