Junit tests, setting up tests without having to create a billion methods  
Author Message
Andrew McDonagh





PostPosted: 2006-2-16 7:01:00 Top

java-programmer, Junit tests, setting up tests without having to create a billion methods James McGill wrote:
> On Wed, 2006-02-15 at 19:42 +0000, Andrew McDonagh wrote:
>
>>email***@***.com wrote:
>>
>>>Is there a more dynamic way of setting up tests? We have legacy test
>>>code that we are trying to convert to junit.
>
>
> I really enjoyed using Fitnesse. A whole different idiom for testing,
> but very flexible and accessible to nonprogrammers.
>
> http://fitnesse.org/
>
>
> Anyway, it sounds like you're working backwards. You've already written
> the code you want to test, which is backwards from TDD, which sort of
> means JUnit isn't exactly the right tool for what you're doing. Still
> it occurs to me that you should be able to automatically generated
> wrappers for your legacy tests, and put those into a testsuite, and be
> done with the legacy stuff and move forward with JUnit.
>
>
>

Hi James,

You seem have have attributed the OPs remarks to me...

That being said, the OP is specifically talking about the case where we
have a legacy code base which wasn't tested with Junit - not that it
wasn't tested. There's no mention of whether TDD was used or not -
though I think we both suspect it wasn't and that the code base was
merely Unit Tested.

Unfortunately, working with legacy code is currently the most common
starting point on projects that adopt TDD. Greenfield projects using TDD
are still rare.

Also, keep in mind, whilst JUnit was developed as a tool to Aid TDD,
Beck et al do realise that some people won't or can't do TDD but still
need a decent Unit Testing tool.

As I'm sure you know - but as an aid for others - TDD is not Unit Testing.

TDD is actually a design methodology that happens to use unit tests to
describe the design. Much like RUP uses UML, etc. In fact this usage of
the term Test has causes so many to concentrate on the testing side of
TDD that some are now starting to question whether a better name could
be found.

e.g.
Behavior Driven Development (http://behaviour-driven.org/)
Specification Driven Development
etc.


Andrew