«

Is there a more dynamic way of setting up tests? We have legacy test
code that we are trying to convert to junit.

I think it is silly to be required to set up a "testFunc(...)" method
for each test.

We'd prefer:

abstract void runTests(Results x);

In your code you implement that and populate Results. If the runTests
blows up, the caller catches the exception and populates TestsResults
on the methods behalf. Easy, breezy, and would have worked just fine
with Java 1.18.

Right now we just have runAllTests, but that makes the junit report too
boring, we want to see each test. It will be too tedious to make a
separate method for each test.

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 think it is silly to be required to set up a "testFunc(...)" method
> for each test.
>
> We'd prefer:
>
> abstract void runTests(Results x);
>
> In your code you implement that and populate Results. If the runTests
> blows up, the caller catches the exception and populates TestsResults
> on the methods behalf. Easy, breezy, and would have worked just fine
> with Java 1.18.
>
> Right now we just have runAllTests, but that makes the junit report too
> boring, we want to see each test. It will be too tedious to make a
> separate method for each test.
>

it would be better to post this message to the JUnit yahoo group where
there is a huge wealth of experience and help available to you.


As it is, what you are asking for is either:

1) Parametrized TestCase - (Google-able)
- If you are testing the same functionality with different data

or

2) Not Applicable to JUnit
- If you are trying to test multiple functionalities with one
method. As each test case (the test method) is supposed be decriptive of
the functionality its testing and so lumping everything into one big
'testTheWorld(stuff)' defeats that.

HTH

Andrew

Andrew McDonagh wrote:
> 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 think it is silly to be required to set up a "testFunc(...)" method
>> for each test.
>>
>> We'd prefer:
>>
>> abstract void runTests(Results x);
>>
>> In your code you implement that and populate Results. If the runTests
>> blows up, the caller catches the exception and populates TestsResults
>> on the methods behalf. Easy, breezy, and would have worked just fine
>> with Java 1.18.
>>
>> Right now we just have runAllTests, but that makes the junit report too
>> boring, we want to see each test. It will be too tedious to make a
>> separate method for each test.
>>
>
> it would be better to post this message to the JUnit yahoo group where
> there is a huge wealth of experience and help available to you.
>
>
> As it is, what you are asking for is either:
>
> 1) Parametrized TestCase - (Google-able)
> - If you are testing the same functionality with different data
>
> or
>
> 2) Not Applicable to JUnit
> - If you are trying to test multiple functionalities with one method.
> As each test case (the test method) is supposed be decriptive of the
> functionality its testing and so lumping everything into one big
> 'testTheWorld(stuff)' defeats that.
>

I hate that "not applicable to JUnit" crap. (No offense Andrew.) It
just bothers me that people try to push you into using the tool only one
way. What if I want an automated integration test? JUnit is able to do
this, even if it goes against the philosophy of its creator.

This is especially true when you've inherited an "engine" that doesn't
already have unit tests. You only really care about the external
interface; you do not have time to reverse engineer every class to
create unit tests. Automated integration tests based on the macro,
known desired behavior of the system is useful here.

The OP might want to look into creating a custom TestRunner.

Ray

--
This signature intentionally left blank.

Raymond DeCampo wrote:
> Andrew McDonagh wrote:
>
>> 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 think it is silly to be required to set up a "testFunc(...)" method
>>> for each test.
>>>
>>> We'd prefer:
>>>
>>> abstract void runTests(Results x);
>>>
>>> In your code you implement that and populate Results. If the runTests
>>> blows up, the caller catches the exception and populates TestsResults
>>> on the methods behalf. Easy, breezy, and would have worked just fine
>>> with Java 1.18.
>>>
>>> Right now we just have runAllTests, but that makes the junit report too
>>> boring, we want to see each test. It will be too tedious to make a
>>> separate method for each test.
>>>
>>
>> it would be better to post this message to the JUnit yahoo group where
>> there is a huge wealth of experience and help available to you.
>>
>>
>> As it is, what you are asking for is either:
>>
>> 1) Parametrized TestCase - (Google-able)
>> - If you are testing the same functionality with different data
>>
>> or
>>
>> 2) Not Applicable to JUnit
>> - If you are trying to test multiple functionalities with one
>> method. As each test case (the test method) is supposed be decriptive
>> of the functionality its testing and so lumping everything into one
>> big 'testTheWorld(stuff)' defeats that.
>>
>
> I hate that "not applicable to JUnit" crap. (No offense Andrew.)

None taken


I was merely trying to point out that JUnit isn't designed for that
scenario (in fact I think the OP has seen this by the remark that the
'test failure message was boring'). But you are right, a custom
TestRunner might be able to do what the OP wants.

> It
> just bothers me that people try to push you into using the tool only one
> way. What if I want an automated integration test? JUnit is able to do
> this, even if it goes against the philosophy of its creator.
>

Sure any of the xUnit frameworks can be used for integration, System,
UAT, SAT, etc tests - it usually comes down to how the test is described
that makes one tool more appropriate than another.

Personally, I would use any of the xUnit frameworks for any testing
other that unit testing. The other tests will (in my situation) has to
be readable by my customers - they don't know Java. But they can read
something like....


Start IE
Browse to http://www.google.com
Enter 'Watir' into searchBox
Click Search button
Check Page contains 'Watir: Web Application Testing in Ruby'

Now in JUnit this test would not be anywhere near as short nor readable
to a non-programmer (be they Customer or tester).

Its Horses-for-courses rather than 'that-aint-what-I-created-it-for'

Andrew


> This is especially true when you've inherited an "engine" that doesn't
> already have unit tests. You only really care about the external
> interface; you do not have time to reverse engineer every class to
> create unit tests.

Agreed, in fact I'd recommend that we don't retrofit unit tests. I
would add a few integration/acceptance tests if possible, using a DSL
something like above.

> Automated integration tests based on the macro,
> known desired behavior of the system is useful here.
>
> The OP might want to look into creating a custom TestRunner.
>
> Ray
>

On Wed, 2006-02-15 at 19:42 +0000, Andrew McDonagh wrote:
> 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.

James McGill wrote:
> On Wed, 2006-02-15 at 19:42 +0000, Andrew McDonagh wrote:
>
>> 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

On Wed, 2006-02-15 at 23:00 +0000, Andrew McDonagh wrote:

> Hi James,
>
> You seem have have attributed the OPs remarks to me...


Didn't mean to, sorry.

> 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.

I still don't see how you'd need "a billion" methods. Your starting
place has some kind of testing. Just wrap all that into a test suite
and be done with it, right? I could be underestimating the size of the
project, but if it's that big, maybe a whole new approach to testing
would be a good thing anyway.

But if the legacy tests work, don't fix 'em!

James McGill wrote:
> On Wed, 2006-02-15 at 23:00 +0000, Andrew McDonagh wrote:
>
>
>>Hi James,
>>
>>You seem have have attributed the OPs remarks to me...
>
>
>
> Didn't mean to, sorry.
>
>
>>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.
>
>
> I still don't see how you'd need "a billion" methods. Your starting
> place has some kind of testing. Just wrap all that into a test suite
> and be done with it, right? I could be underestimating the size of the
> project, but if it's that big, maybe a whole new approach to testing
> would be a good thing anyway.
>

No I don't see why the Op does either...

> But if the legacy tests work, don't fix 'em!
>

Exactly!

I found code that works:

Let's say you need to write a junit test that tests several method
calls.

For example, let's say you wrote a method called square(int x) which
takes x and multiples it by itself.


public static Test suite() {
TestSuite suite = new TestSuite();
for(int i=0;i<65535;i++){
final int x=i;
TestCase test = new TestCase(i+"*"+i) {
public void runTest() {
assertEqual(""+square(x),""+(x*x));
}
};
suite.addTest(test);
}
return suite;
}