Parameterized Tests, a proposal

[Malte Finsterwalder-2]

Hi,

I just got around to looking into parameterized tests a little more.
But it confirmed the impression I got when they came out with JUnit 4.
They are sooo clunky, that I rather write a test that calls a
helper-method with parameters instead.

But this time I had time to ask myself: Why is it so clunky?
In what way could it be better.

So I came up with an idea, how I would like it to be.
And here is an example:

@RunWith(Parameterized.class)
public class MyParameterizedTest {

        private Object[] data = new Object[][] {
                {"param1", 2, 3},
                {"other", 5, 99},
                {"more", 234, 5875727343}
        };
       
        // The parameter given as "data" here, specifies that
        // attribute, that contains the parameters for the test
        @ParameterizedTest("data")
        public void testWhatever(String str, int i, long j) {
                // This method gets called 3 times
                // once for each line in the above Object[]

                // do whatever here
        }

        @Test
        public void plainNonParameterizedTest() {
                // this is a normal unit test that is
                // called just once
        }
}

I think it's a lot easier this way.
It allows mixing of parameterized tests and non parameterized tests, if
you like.
I allows for several parameterized tests in a single class.
And I don't see disadvantages.

It could be even simpler, if it were incorporated into the existing
JUnit Test-annotation, like so:

// no @RunWith-Annotation here
public class MyParameterizedTest {

        private Object[] data = new Object[][] {
                {"param1", 2, 3},
                {"other", 5, 99},
                {"more", 234, 5875727343}
        };
       
        // The parameter given as "data" here, specifies that
        // attribute, that contains the parameters for the test
        // Use of standard Test-annotation with a new parameter
        @Test(parameterized="data")
        public void testWhatever(String str, int i, long j) {
                // This method gets called 3 times
                // once for each line in the above Object[]

                // do whatever here
        }
}

What do you think?

I already tried to implement the first version, since it's non
intrusive, but looking into extending JUnit, I found that it's a pain in
the behind, if you don't want to extends internals-stuff.
But maybe I'm just misunderstanding or missing things.
But that's another story for another post... shortly...

Greetings,
    Malte

[kentb]

Malte,
 
I agree that the current arrangement for parameterized tests is clunky.
However, the solution you propose--different tests in the same class being
parameterized by different (or even no) data, contradicts a fundamental
element of JUnit's design: one class/one fixture. Your proposal is akin, it
seems to me, to having different tests in the same class use different sets
of @Befores. You could do that using a similar syntax to that outlined
below, but it would make it harder to read tests declaratively. With the
current design, if I want to know what data a test will have available, I
read the @Befores (and @Parameters). Then I can read all the tests assuming
those are the conditions under which it will execute. If I have a diffferent
fixture, I go to a different class.
 
Can you tell me a little more about what benefits you see from your proposed
arrangement and in which circumstances it would be superior to having tests
with different fixtures in different classes?
 
Regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Malte Finsterwalder
Sent: Wednesday, July 09, 2008 12:01 AM
To: junit YahooGroup
Subject: [junit] Parameterized Tests, a proposal



Hi,

I just got around to looking into parameterized tests a little more.
But it confirmed the impression I got when they came out with JUnit 4.
They are sooo clunky, that I rather write a test that calls a
helper-method with parameters instead.

But this time I had time to ask myself: Why is it so clunky?
In what way could it be better.

So I came up with an idea, how I would like it to be.
And here is an example:

@RunWith(Parameterized.class)
public class MyParameterizedTest {

private Object[] data = new Object[][] {
{"param1", 2, 3},
{"other", 5, 99},
{"more", 234, 5875727343}
};

// The parameter given as "data" here, specifies that
// attribute, that contains the parameters for the test
@ParameterizedTest("data")
public void testWhatever(String str, int i, long j) {
// This method gets called 3 times
// once for each line in the above Object[]

// do whatever here
}

@Test
public void plainNonParameterizedTest() {
// this is a normal unit test that is
// called just once
}
}

I think it's a lot easier this way.
It allows mixing of parameterized tests and non parameterized tests, if
you like.
I allows for several parameterized tests in a single class.
And I don't see disadvantages.

It could be even simpler, if it were incorporated into the existing
JUnit Test-annotation, like so:

// no @RunWith-Annotation here
public class MyParameterizedTest {

private Object[] data = new Object[][] {
{"param1", 2, 3},
{"other", 5, 99},
{"more", 234, 5875727343}
};

// The parameter given as "data" here, specifies that
// attribute, that contains the parameters for the test
// Use of standard Test-annotation with a new parameter
@Test(parameterized="data")
public void testWhatever(String str, int i, long j) {
// This method gets called 3 times
// once for each line in the above Object[]

// do whatever here
}
}

What do you think?

I already tried to implement the first version, since it's non
intrusive, but looking into extending JUnit, I found that it's a pain in
the behind, if you don't want to extends internals-stuff.
But maybe I'm just misunderstanding or missing things.
But that's another story for another post... shortly...

Greetings,
Malte


 


[Non-text portions of this message have been removed]

[Malte Finsterwalder-2]

Hi Kent,

Kent Beck wrote:
> I agree that the current arrangement for parameterized tests is clunky.

Do you have other ideas about how to improve it?

> However, the solution you propose--different tests in the same class being
> parameterized by different (or even no) data, contradicts a fundamental
> element of JUnit's design: one class/one fixture.
 >

> Your proposal is akin, it
> seems to me, to having different tests in the same class use different sets
> of @Befores. You could do that using a similar syntax to that outlined
> below, but it would make it harder to read tests declaratively. With the
> current design, if I want to know what data a test will have available, I
> read the @Befores (and @Parameters). Then I can read all the tests assuming
> those are the conditions under which it will execute. If I have a diffferent
> fixture, I go to a different class.
>
> Can you tell me a little more about what benefits you see from your proposed
> arrangement and in which circumstances it would be superior to having tests
> with different fixtures in different classes?

I don't think that the parameterization and the test fixture are the same.

And I think it's normal to have part of my test fixture shared in a
Before-Method. And then I extend (or modify) this setup slightly inside
my different test methods.

I want to do some tests with a customer object, for example how the
customer responds to billing differnt items to his account.
Some of theses tests can be parameterized, some can't.

e.g. I want to write a test that billing "null" is not allowed and
throws an exception. This test is not parameterized.
Then I want to bill different goods and I want to see, that the customer
responds correctly by say calculating a correct bonus, according to his
state. To check this, I need to bill 10 different goods, cause some of
them have a bonus, some don't, etc.
These 10 tests can be parameterized with a good to bill and the
resulting bonus. They still use the same fixture, namely the customer
object.

I would like all these tests in the same class, since they use the same
fixture and test a coherent set of functionality.

Does that make more sense now?

BTW: I learned, that testNG uses an approach like the one I proposed.
Ans reading up on Theries, I noticed, that they have a somewhat similar
approach as well.

Regard,
    Malte

> From: junit@... <mailto:junit%40yahoogroups.com>
> [mailto:junit@... <mailto:junit%40yahoogroups.com>] On Behalf Of
> Malte Finsterwalder
> Sent: Wednesday, July 09, 2008 12:01 AM
> To: junit YahooGroup
> Subject: [junit] Parameterized Tests, a proposal
>
> Hi,
>
> I just got around to looking into parameterized tests a little more.
> But it confirmed the impression I got when they came out with JUnit 4.
> They are sooo clunky, that I rather write a test that calls a
> helper-method with parameters instead.
>
> But this time I had time to ask myself: Why is it so clunky?
> In what way could it be better.
>
> So I came up with an idea, how I would like it to be.
> And here is an example:
>
> @RunWith(Parameterized.class)
> public class MyParameterizedTest {
>
> private Object[] data = new Object[][] {
> {"param1", 2, 3},
> {"other", 5, 99},
> {"more", 234, 5875727343}
> };
>
> // The parameter given as "data" here, specifies that
> // attribute, that contains the parameters for the test
> @ParameterizedTest("data")
> public void testWhatever(String str, int i, long j) {
> // This method gets called 3 times
> // once for each line in the above Object[]
>
> // do whatever here
> }
>
> @Test
> public void plainNonParameterizedTest() {
> // this is a normal unit test that is
> // called just once
> }
> }
>
> I think it's a lot easier this way.
> It allows mixing of parameterized tests and non parameterized tests, if
> you like.
> I allows for several parameterized tests in a single class.
> And I don't see disadvantages.
>
> It could be even simpler, if it were incorporated into the existing
> JUnit Test-annotation, like so:
>
> // no @RunWith-Annotation here
> public class MyParameterizedTest {
>
> private Object[] data = new Object[][] {
> {"param1", 2, 3},
> {"other", 5, 99},
> {"more", 234, 5875727343}
> };
>
> // The parameter given as "data" here, specifies that
> // attribute, that contains the parameters for the test
> // Use of standard Test-annotation with a new parameter
> @Test(parameterized="data")
> public void testWhatever(String str, int i, long j) {
> // This method gets called 3 times
> // once for each line in the above Object[]
>
> // do whatever here
> }
> }
>
> What do you think?
>
> I already tried to implement the first version, since it's non
> intrusive, but looking into extending JUnit, I found that it's a pain in
> the behind, if you don't want to extends internals-stuff.
> But maybe I'm just misunderstanding or missing things.
> But that's another story for another post... shortly...
>
> Greetings,
> Malte

[toalexsmail]

--- In junit@..., Malte Finsterwalder <malte@...> wrote:
>
> > However, the solution you propose--different tests in the same
class being
> > parameterized by different (or even no) data, contradicts a
fundamental
> > element of JUnit's design: one class/one fixture.
>  >
> > Your proposal is akin, it
> > seems to me, to having different tests in the same class use
different sets
> > of @Befores. You could do that using a similar syntax to that outlined
> > below, but it would make it harder to read tests declaratively.
With the
> > current design, if I want to know what data a test will have
available, I
> > read the @Befores (and @Parameters). Then I can read all the tests
assuming
> > those are the conditions under which it will execute. If I have a
diffferent
> > fixture, I go to a different class.
> >
> > Can you tell me a little more about what benefits you see from
your proposed
> > arrangement and in which circumstances it would be superior to
having tests
> > with different fixtures in different classes?
>
> I don't think that the parameterization and the test fixture are the
same.

>
> And I think it's normal to have part of my test fixture shared in a
> Before-Method. And then I extend (or modify) this setup slightly inside
> my different test methods.
>
> I want to do some tests with a customer object, for example how the
> customer responds to billing differnt items to his account.
> Some of theses tests can be parameterized, some can't.
>
> e.g. I want to write a test that billing "null" is not allowed and
> throws an exception. This test is not parameterized.
> Then I want to bill different goods and I want to see, that the

customer

> responds correctly by say calculating a correct bonus, according to his
> state. To check this, I need to bill 10 different goods, cause some of
> them have a bonus, some don't, etc.
> These 10 tests can be parameterized with a good to bill and the
> resulting bonus. They still use the same fixture, namely the customer
> object.
>
> I would like all these tests in the same class, since they use the same
> fixture and test a coherent set of functionality.
>
> Does that make more sense now?
>

It does make sense for me. :-)

[kentb]

Malte,
 
I don't have a better idea for parameterized tests. The current interface
requires a lot of syntactic "noise". We're open to proposals that simplify
the API.
 
As far as having multiple fixtures in a single class, I don't see the value
of moving away from the current model. Users can already apply inheritance
to factor out common fixturing. It's true that "one class=one fixture"
hasn't been very effectively communicated, but that's something we can work
on. I'd like to see sets of real concrete tests that would be made simpler
by allowing different parameters for different tests in the same class.
 
Overall, I think what we have here is one of those design decisions that can
reasonably go either way, depending on the underlying values of the project
developers. We've always chosen simplicity of the API over flexibility if
the two are in conflict. Other projects have other values and decide
differently.
 
Regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Malte Finsterwalder
Sent: Monday, July 14, 2008 2:01 AM
To: junit@...
Subject: Re: [junit] Parameterized Tests, a proposal



Hi Kent,

Kent Beck wrote:
> I agree that the current arrangement for parameterized tests is clunky.

Do you have other ideas about how to improve it?

> However, the solution you propose--different tests in the same class being
> parameterized by different (or even no) data, contradicts a fundamental
> element of JUnit's design: one class/one fixture.
>
> Your proposal is akin, it
> seems to me, to having different tests in the same class use different
sets
> of @Befores. You could do that using a similar syntax to that outlined
> below, but it would make it harder to read tests declaratively. With the
> current design, if I want to know what data a test will have available, I
> read the @Befores (and @Parameters). Then I can read all the tests
assuming
> those are the conditions under which it will execute. If I have a
diffferent
> fixture, I go to a different class.
>
> Can you tell me a little more about what benefits you see from your
proposed
> arrangement and in which circumstances it would be superior to having
tests
> with different fixtures in different classes?

I don't think that the parameterization and the test fixture are the same.

And I think it's normal to have part of my test fixture shared in a
Before-Method. And then I extend (or modify) this setup slightly inside
my different test methods.

I want to do some tests with a customer object, for example how the
customer responds to billing differnt items to his account.
Some of theses tests can be parameterized, some can't.

e.g. I want to write a test that billing "null" is not allowed and
throws an exception. This test is not parameterized.
Then I want to bill different goods and I want to see, that the customer
responds correctly by say calculating a correct bonus, according to his
state. To check this, I need to bill 10 different goods, cause some of
them have a bonus, some don't, etc.
These 10 tests can be parameterized with a good to bill and the
resulting bonus. They still use the same fixture, namely the customer
object.

I would like all these tests in the same class, since they use the same
fixture and test a coherent set of functionality.

Does that make more sense now?

BTW: I learned, that testNG uses an approach like the one I proposed.
Ans reading up on Theries, I noticed, that they have a somewhat similar
approach as well.

Regard,
Malte

> From: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
<mailto:junit%40yahoogroups.com>
> [mailto:junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
<mailto:junit%40yahoogroups.com>] On Behalf Of

> Malte Finsterwalder
> Sent: Wednesday, July 09, 2008 12:01 AM
> To: junit YahooGroup
> Subject: [junit] Parameterized Tests, a proposal
>
> Hi,
>
> I just got around to looking into parameterized tests a little more.
> But it confirmed the impression I got when they came out with JUnit 4.
> They are sooo clunky, that I rather write a test that calls a
> helper-method with parameters instead.
>
> But this time I had time to ask myself: Why is it so clunky?
> In what way could it be better.
>
> So I came up with an idea, how I would like it to be.
> And here is an example:
>
> @RunWith(Parameterized.class)
> public class MyParameterizedTest {
>
> private Object[] data = new Object[][] {
> {"param1", 2, 3},
> {"other", 5, 99},
> {"more", 234, 5875727343}
> };
>
> // The parameter given as "data" here, specifies that
> // attribute, that contains the parameters for the test
> @ParameterizedTest("data")
> public void testWhatever(String str, int i, long j) {
> // This method gets called 3 times
> // once for each line in the above Object[]
>
> // do whatever here
> }
>
> @Test
> public void plainNonParameterizedTest() {
> // this is a normal unit test that is
> // called just once
> }
> }
>
> I think it's a lot easier this way.
> It allows mixing of parameterized tests and non parameterized tests, if
> you like.
> I allows for several parameterized tests in a single class.
> And I don't see disadvantages.
>
> It could be even simpler, if it were incorporated into the existing
> JUnit Test-annotation, like so:
>
> // no @RunWith-Annotation here
> public class MyParameterizedTest {
>
> private Object[] data = new Object[][] {
> {"param1", 2, 3},
> {"other", 5, 99},
> {"more", 234, 5875727343}
> };
>
> // The parameter given as "data" here, specifies that
> // attribute, that contains the parameters for the test
> // Use of standard Test-annotation with a new parameter
> @Test(parameterized="data")
> public void testWhatever(String str, int i, long j) {
> // This method gets called 3 times
> // once for each line in the above Object[]
>
> // do whatever here
> }
> }
>
> What do you think?
>
> I already tried to implement the first version, since it's non
> intrusive, but looking into extending JUnit, I found that it's a pain in
> the behind, if you don't want to extends internals-stuff.
> But maybe I'm just misunderstanding or missing things.
> But that's another story for another post... shortly...
>
> Greetings,
> Malte

 


[Non-text portions of this message have been removed]

[Malte Finsterwalder-2]

Hey Kent,

I think we still have a missunderstanding to some degree.

My focus is not to provide many different fixtures in one test-class. I
agree that one class = one fixture is a good idea. And it's my normal
working style. I admit that my approach allows for multiple fixtures,
but that's not my main focus.
My main focus is, to be able to parameterize easily.
And I do think it's ok to have some tests that are parameterized
combined with some tests that are not parameterized, if the rest of the
fixture is the same.

Greetings,
    Malte

Kent Beck wrote:

> Malte,
>  
> I don't have a better idea for parameterized tests. The current interface
> requires a lot of syntactic "noise". We're open to proposals that simplify
> the API.
>  
> As far as having multiple fixtures in a single class, I don't see the value
> of moving away from the current model. Users can already apply inheritance
> to factor out common fixturing. It's true that "one class=one fixture"
> hasn't been very effectively communicated, but that's something we can work
> on. I'd like to see sets of real concrete tests that would be made simpler
> by allowing different parameters for different tests in the same class.
>  
> Overall, I think what we have here is one of those design decisions that can
> reasonably go either way, depending on the underlying values of the project
> developers. We've always chosen simplicity of the API over flexibility if
> the two are in conflict. Other projects have other values and decide
> differently.
>  
> Regards,
>  
> Kent Beck
> Three Rivers Institute
>
>   _____  
>
> From: junit@... [mailto:junit@...] On Behalf Of
> Malte Finsterwalder
> Sent: Monday, July 14, 2008 2:01 AM
> To: junit@...
> Subject: Re: [junit] Parameterized Tests, a proposal
>
>
>
> Hi Kent,
>
> Kent Beck wrote:
>> I agree that the current arrangement for parameterized tests is clunky.
>
> Do you have other ideas about how to improve it?
>
>> However, the solution you propose--different tests in the same class being
>> parameterized by different (or even no) data, contradicts a fundamental
>> element of JUnit's design: one class/one fixture.
>>
>> Your proposal is akin, it
>> seems to me, to having different tests in the same class use different
> sets
>> of @Befores. You could do that using a similar syntax to that outlined
>> below, but it would make it harder to read tests declaratively. With the
>> current design, if I want to know what data a test will have available, I
>> read the @Befores (and @Parameters). Then I can read all the tests
> assuming
>> those are the conditions under which it will execute. If I have a
> diffferent
>> fixture, I go to a different class.
>>
>> Can you tell me a little more about what benefits you see from your
> proposed
>> arrangement and in which circumstances it would be superior to having
> tests
>> with different fixtures in different classes?
>
> I don't think that the parameterization and the test fixture are the same.
>
> And I think it's normal to have part of my test fixture shared in a
> Before-Method. And then I extend (or modify) this setup slightly inside
> my different test methods.
>
> I want to do some tests with a customer object, for example how the
> customer responds to billing differnt items to his account.
> Some of theses tests can be parameterized, some can't.
>
> e.g. I want to write a test that billing "null" is not allowed and
> throws an exception. This test is not parameterized.
> Then I want to bill different goods and I want to see, that the customer
> responds correctly by say calculating a correct bonus, according to his
> state. To check this, I need to bill 10 different goods, cause some of
> them have a bonus, some don't, etc.
> These 10 tests can be parameterized with a good to bill and the
> resulting bonus. They still use the same fixture, namely the customer
> object.
>
> I would like all these tests in the same class, since they use the same
> fixture and test a coherent set of functionality.
>
> Does that make more sense now?
>
> BTW: I learned, that testNG uses an approach like the one I proposed.
> Ans reading up on Theries, I noticed, that they have a somewhat similar
> approach as well.
>
> Regard,
> Malte
>
>> From: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
> <mailto:junit%40yahoogroups.com>
>> [mailto:junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
> <mailto:junit%40yahoogroups.com>] On Behalf Of
>> Malte Finsterwalder
>> Sent: Wednesday, July 09, 2008 12:01 AM
>> To: junit YahooGroup
>> Subject: [junit] Parameterized Tests, a proposal
>>
>> Hi,
>>
>> I just got around to looking into parameterized tests a little more.
>> But it confirmed the impression I got when they came out with JUnit 4.
>> They are sooo clunky, that I rather write a test that calls a
>> helper-method with parameters instead.
>>
>> But this time I had time to ask myself: Why is it so clunky?
>> In what way could it be better.
>>
>> So I came up with an idea, how I would like it to be.
>> And here is an example:
>>
>> @RunWith(Parameterized.class)
>> public class MyParameterizedTest {
>>
>> private Object[] data = new Object[][] {
>> {"param1", 2, 3},
>> {"other", 5, 99},
>> {"more", 234, 5875727343}
>> };
>>
>> // The parameter given as "data" here, specifies that
>> // attribute, that contains the parameters for the test
>> @ParameterizedTest("data")
>> public void testWhatever(String str, int i, long j) {
>> // This method gets called 3 times
>> // once for each line in the above Object[]
>>
>> // do whatever here
>> }
>>
>> @Test
>> public void plainNonParameterizedTest() {
>> // this is a normal unit test that is
>> // called just once
>> }
>> }
>>
>> I think it's a lot easier this way.
>> It allows mixing of parameterized tests and non parameterized tests, if
>> you like.
>> I allows for several parameterized tests in a single class.
>> And I don't see disadvantages.
>>
>> It could be even simpler, if it were incorporated into the existing
>> JUnit Test-annotation, like so:
>>
>> // no @RunWith-Annotation here
>> public class MyParameterizedTest {
>>
>> private Object[] data = new Object[][] {
>> {"param1", 2, 3},
>> {"other", 5, 99},
>> {"more", 234, 5875727343}
>> };
>>
>> // The parameter given as "data" here, specifies that
>> // attribute, that contains the parameters for the test
>> // Use of standard Test-annotation with a new parameter
>> @Test(parameterized="data")
>> public void testWhatever(String str, int i, long j) {
>> // This method gets called 3 times
>> // once for each line in the above Object[]
>>
>> // do whatever here
>> }
>> }
>>
>> What do you think?
>>
>> I already tried to implement the first version, since it's non
>> intrusive, but looking into extending JUnit, I found that it's a pain in
>> the behind, if you don't want to extends internals-stuff.
>> But maybe I'm just misunderstanding or missing things.
>> But that's another story for another post... shortly...
>>
>> Greetings,
>> Malte

[kentb]

Dear Malte,
 
I think I understand your position. The proposed interface conflicts with
the basic JUnit value of simplicity--all tests in a class run with the same
environment. Thinking about it a bit I'm not sure it fits well with the
dimensions of programmability we've added to BlockJUnit4ClassRunner, either,
which would be a shame. If you try to write a custom runner I'd like to hear
how it goes.
 
Regards,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
Malte Finsterwalder
Sent: Thursday, July 17, 2008 11:26 AM
To: junit@...
Subject: Re: [junit] Parameterized Tests, a proposal



Hey Kent,

I think we still have a missunderstanding to some degree.

My focus is not to provide many different fixtures in one test-class. I
agree that one class = one fixture is a good idea. And it's my normal
working style. I admit that my approach allows for multiple fixtures,
but that's not my main focus.
My main focus is, to be able to parameterize easily.
And I do think it's ok to have some tests that are parameterized
combined with some tests that are not parameterized, if the rest of the
fixture is the same.

Greetings,
Malte

Kent Beck wrote:
> Malte,
>
> I don't have a better idea for parameterized tests. The current interface
> requires a lot of syntactic "noise". We're open to proposals that simplify
> the API.
>
> As far as having multiple fixtures in a single class, I don't see the
value
> of moving away from the current model. Users can already apply inheritance
> to factor out common fixturing. It's true that "one class=one fixture"
> hasn't been very effectively communicated, but that's something we can
work
> on. I'd like to see sets of real concrete tests that would be made simpler
> by allowing different parameters for different tests in the same class.
>
> Overall, I think what we have here is one of those design decisions that
can
> reasonably go either way, depending on the underlying values of the
project

> developers. We've always chosen simplicity of the API over flexibility if
> the two are in conflict. Other projects have other values and decide
> differently.
>
> Regards,
>
> Kent Beck
> Three Rivers Institute
>
> _____
>
> From: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com

[mailto:junit@yahoogroups. <mailto:junit%40yahoogroups.com> com] On Behalf
Of

> Malte Finsterwalder
> Sent: Monday, July 14, 2008 2:01 AM
> To: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
> Subject: Re: [junit] Parameterized Tests, a proposal
>
>
>
> Hi Kent,
>
> Kent Beck wrote:
>> I agree that the current arrangement for parameterized tests is clunky.
>
> Do you have other ideas about how to improve it?
>
>> However, the solution you propose--different tests in the same class

being

>> parameterized by different (or even no) data, contradicts a fundamental
>> element of JUnit's design: one class/one fixture.
>>
>> Your proposal is akin, it
>> seems to me, to having different tests in the same class use different
> sets
>> of @Befores. You could do that using a similar syntax to that outlined
>> below, but it would make it harder to read tests declaratively. With the
>> current design, if I want to know what data a test will have available, I
>> read the @Befores (and @Parameters). Then I can read all the tests
> assuming
>> those are the conditions under which it will execute. If I have a
> diffferent
>> fixture, I go to a different class.
>>
>> Can you tell me a little more about what benefits you see from your
> proposed
>> arrangement and in which circumstances it would be superior to having
> tests
>> with different fixtures in different classes?
>
> I don't think that the parameterization and the test fixture are the same.
>
> And I think it's normal to have part of my test fixture shared in a
> Before-Method. And then I extend (or modify) this setup slightly inside
> my different test methods.
>
> I want to do some tests with a customer object, for example how the
> customer responds to billing differnt items to his account.
> Some of theses tests can be parameterized, some can't.
>
> e.g. I want to write a test that billing "null" is not allowed and
> throws an exception. This test is not parameterized.
> Then I want to bill different goods and I want to see, that the customer
> responds correctly by say calculating a correct bonus, according to his
> state. To check this, I need to bill 10 different goods, cause some of
> them have a bonus, some don't, etc.
> These 10 tests can be parameterized with a good to bill and the
> resulting bonus. They still use the same fixture, namely the customer
> object.
>
> I would like all these tests in the same class, since they use the same
> fixture and test a coherent set of functionality.
>
> Does that make more sense now?
>
> BTW: I learned, that testNG uses an approach like the one I proposed.
> Ans reading up on Theries, I noticed, that they have a somewhat similar
> approach as well.
>
> Regard,
> Malte
>
>> From: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
> <mailto:junit%40yahoogroups.com>
>> [mailto:junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
> <mailto:junit%40yahoogroups.com>] On Behalf Of
>> Malte Finsterwalder
>> Sent: Wednesday, July 09, 2008 12:01 AM
>> To: junit YahooGroup
>> Subject: [junit] Parameterized Tests, a proposal
>>
>> Hi,
>>
>> I just got around to looking into parameterized tests a little more.
>> But it confirmed the impression I got when they came out with JUnit 4.
>> They are sooo clunky, that I rather write a test that calls a
>> helper-method with parameters instead.
>>
>> But this time I had time to ask myself: Why is it so clunky?
>> In what way could it be better.
>>
>> So I came up with an idea, how I would like it to be.
>> And here is an example:
>>
>> @RunWith(Parameterized.class)
>> public class MyParameterizedTest {
>>
>> private Object[] data = new Object[][] {
>> {"param1", 2, 3},
>> {"other", 5, 99},
>> {"more", 234, 5875727343}
>> };
>>
>> // The parameter given as "data" here, specifies that
>> // attribute, that contains the parameters for the test
>> @ParameterizedTest("data")
>> public void testWhatever(String str, int i, long j) {
>> // This method gets called 3 times
>> // once for each line in the above Object[]
>>
>> // do whatever here
>> }
>>
>> @Test
>> public void plainNonParameterizedTest() {
>> // this is a normal unit test that is
>> // called just once
>> }
>> }
>>
>> I think it's a lot easier this way.
>> It allows mixing of parameterized tests and non parameterized tests, if
>> you like.
>> I allows for several parameterized tests in a single class.
>> And I don't see disadvantages.
>>
>> It could be even simpler, if it were incorporated into the existing
>> JUnit Test-annotation, like so:
>>
>> // no @RunWith-Annotation here
>> public class MyParameterizedTest {
>>
>> private Object[] data = new Object[][] {
>> {"param1", 2, 3},
>> {"other", 5, 99},
>> {"more", 234, 5875727343}
>> };
>>
>> // The parameter given as "data" here, specifies that
>> // attribute, that contains the parameters for the test
>> // Use of standard Test-annotation with a new parameter
>> @Test(parameterized="data")
>> public void testWhatever(String str, int i, long j) {
>> // This method gets called 3 times
>> // once for each line in the above Object[]
>>
>> // do whatever here
>> }
>> }
>>
>> What do you think?
>>
>> I already tried to implement the first version, since it's non
>> intrusive, but looking into extending JUnit, I found that it's a pain in
>> the behind, if you don't want to extends internals-stuff.
>> But maybe I'm just misunderstanding or missing things.
>> But that's another story for another post... shortly...
>>
>> Greetings,
>> Malte

 


[Non-text portions of this message have been removed]