views:

282

answers:

3

I know it is possible to create a TestCase or TestSuite with the wizard within JUnit, but how does one sync the code after the class under the test has been modified, such as method signature modification or newly added methods. I would like my TestCases to be able to sync up (remove or add) those changed methods/parameters/method signatures within my TestCases.

I tried searching on Google to no avail, maybe there is an eclipse plugin for that?

A: 

If you change method signatures using the automated refactoring, then the test cases - and all other code that calls the method - will be automatically updated.

For newly added methods, I don't know of a way to have the test class automatically updated.

Carl Manaster
+2  A: 

As has been mentioned before, refactorings such as renames or moves will be automatically reflected in the test cases as long as you refactor using the Eclipse tooling and not by manually renaming for example.

As for new methods, it's impossible to generate tests automatically. Of course there are some exceptions for auto-generated code where you control the generation and where you could generate test cases as well but for "normal" manual code the best you could do was to provide stubs (empty methods), and what's the use in that?

A better approach is to track code coverage using a tool such as Cobertura or Emma, which happens to have a nice Eclipse plugin that allows you to see, inside your source code, what code is being covered by tests and which isn't. This then is your report of where you need more testing.

Boris Terzic
Yeah I see, I thought there was maybe something beyond code coverage but I think that will do anyways :) Thanks a lot for the clear answer
Steven Rosato
A: 

Tests which have a 1-1 relationship with the structure of the production code are a test smell. It's much better for the tests to be written as a specification of the system's behaviour (~one test per behaviour), instead of having tests generated based on the production code (~one test per method).

Quoted from http://blog.daveastels.com/files/BDD_Intro.pdf

When you realize that it's all about specifying behaviour and not writing tests, your point of view shifts. Suddenly the idea of having a Test class for each of your production classes is ridiculously limiting. And the thought of testing each of your methods with its own test method (in a 1-1 relationship) will be laughable.

Esko Luontola
Thx for the reply. A short while after posting this question I realized that writing tests based on behaviour is the way to go and therefore that is what I am doing. I do not really need unit test synchronizing now :) I fully support that point of view (unit testing the behaviour). Adding up, this comes up easier to read tests since the method name contains the behaviour it tests.
Steven Rosato