You can see some here from a recent JUnit course I taught:

http://www.cafeaulait.org/slides/catt/junit/52.html

and work forward for a few slides

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Hello Narasimha,

On 2/1/07, Elliotte Harold <elharo@...> wrote:
> You can see some here from a recent JUnit course I taught:
>  http://www.cafeaulait.org/slides/catt/junit/52.html
>  and work forward for a few slides

Note that Elliotte's example is not an example of using J.B.'s
ParameterizedTestCase but an example of implementing the Parameterized
TestCase *pattern*.

Lasse

Hi All

        Thanks for responses. At last I manage to make it work out.
Actually in J.B's samples I found two ParameterizedTestSuite classes the
one under package junit.extensions.cookbook is much easier to implement.
Which is having a method addParameterizedTests to accept the tests with
parameters.

Elliotte course is really use full for quick ref of all the features of
JUnit.

Thanks & Regards
Narasimha

________________________________

From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
Lasse Koskela
Sent: Thursday, February 01, 2007 6:39 AM
To: junit@yahoogroups.com
Subject: Re: [junit] Need some detailed example of
ParameterizedTestSuite



Hello Narasimha,

On 2/1/07, Elliotte Harold <elharo@...
<mailto:elharo%40metalab.unc.edu> > wrote:
> You can see some here from a recent JUnit course I taught:
> http://www.cafeaulait.org/slides/catt/junit/52.html
<http://www.cafeaulait.org/slides/catt/junit/52.html>
> and work forward for a few slides

Note that Elliotte's example is not an example of using J.B.'s
ParameterizedTestCase but an example of implementing the Parameterized
TestCase *pattern*.

Lasse





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

Narasimha_Tadepalli@... wrote:

> Thanks for responses. At last I manage to make it work out.
> Actually in J.B's samples I found two ParameterizedTestSuite classes the
> one under package junit.extensions.cookbook is much easier to implement.
> Which is having a method addParameterizedTests to accept the tests with
> parameters.

I'm glad you were able to find something, and I'm sorry I couldn't help
you more.

Take care.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

No Problem at all. But could you post me here if you have any other new
articles on JUnit framework or Testing .

-Narasimha

________________________________

From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
J. B. Rainsberger
Sent: Thursday, February 01, 2007 2:04 PM
To: junit@yahoogroups.com
Subject: Re: [junit] Need some detailed example of
ParameterizedTestSuite



Narasimha_Tadepalli@... <mailto:Narasimha_Tadepalli%40Dell.com>
wrote:

> Thanks for responses. At last I manage to make it work out.
> Actually in J.B's samples I found two ParameterizedTestSuite classes
the
> one under package junit.extensions.cookbook is much easier to
implement.
> Which is having a method addParameterizedTests to accept the tests
with
> parameters.

I'm glad you were able to find something, and I'm sorry I couldn't help
you more.

Take care.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca <http://www.jbrains.ca>

Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice





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

Markus,

Have you tried going to

http://sourceforge.net/project/showfiles.php?group_id=15278

and clicking on "Show older releases"?  Thanks,

    David Saff

On 1/31/07, markuspeterbaum <markuspeterbaum@...> wrote:
> For a long time I have been working with subversion, and now I tried
> to get back to cvs for downloading the sources for version 3.8.1.
> I searched on junit.org but could only find the download for 4.1.
> On http://sourceforge.net/project/ I found a newer version 4.2 plus
> elder versions including 3.8.1. But they only contained the classes of
> the library plus some sources to test, but I need the sources of the
> framework itself. I browsed the cvs source repository, however I saw
> some tags and branches and a set of other selection mainly for 4.0,
> but I did not find any hint how to get the 3.8.1. sources
>
> Would anybody know the precise cvs repository and password - or else
> send me sources to mbjava@...?
>
> Thanks a lot for help
>
> Markus
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Hi David,

Thanks for your hint. Yes I've been there and downloaded the zip and
I just tried it again to check if I didn't oversee something. But in
the zip file I find only the sources for examples and general tests
for junit, but I do not find the sources of the Junit framework
itself (like AssertEqual.java, TestRunner.java etc.)

On the same homepage, I've also 'cvs browsed' the repository for
sources. I can select sticky tags, but the names appearing have no
link to anything 3.8.1...

Thanks for your help

Markus


--- In junit@yahoogroups.com, "David Saff" <saff@...> wrote:
>
> Markus,
>
> Have you tried going to
>
> http://sourceforge.net/project/showfiles.php?group_id=15278
>
> and clicking on "Show older releases"?  Thanks,
>
>    David Saff
>
> On 1/31/07, markuspeterbaum <markuspeterbaum@...> wrote:
> > For a long time I have been working with subversion, and now I
tried
> > to get back to cvs for downloading the sources for version 3.8.1.
> > I searched on junit.org but could only find the download for 4.1.
> > On http://sourceforge.net/project/ I found a newer version 4.2
plus
> > elder versions including 3.8.1. But they only contained the
classes of
> > the library plus some sources to test, but I need the sources of
the
> > framework itself. I browsed the cvs source repository, however I
saw
> > some tags and branches and a set of other selection mainly for
4.0,
> > but I did not find any hint how to get the 3.8.1. sources
> >
> > Would anybody know the precise cvs repository and password - or
else
> > send me sources to mbjava@...?
> >
> > Thanks a lot for help
> >
> > Markus
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

Markus,

My bad.  You had said as much the first time, but I saw the source
directory, and didn't look hard enough.

I'm sure that some CVS archeology, if nothing else, can get what you
want.  I'll take a look at it, but I can't promise anything before
sometime next week.  Sorry,

    David Saff

On 2/2/07, markuspeterbaum <markuspeterbaum@...> wrote:
> Hi David,
>
> Thanks for your hint. Yes I've been there and downloaded the zip and
> I just tried it again to check if I didn't oversee something. But in
> the zip file I find only the sources for examples and general tests
> for junit, but I do not find the sources of the Junit framework
> itself (like AssertEqual.java, TestRunner.java etc.)
>
> On the same homepage, I've also 'cvs browsed' the repository for
> sources. I can select sticky tags, but the names appearing have no
> link to anything 3.8.1...
>
> Thanks for your help
>
> Markus
>
>
> --- In junit@yahoogroups.com, "David Saff" <saff@...> wrote:
> >
> > Markus,
> >
> > Have you tried going to
> >
> > http://sourceforge.net/project/showfiles.php?group_id=15278
> >
> > and clicking on "Show older releases"?  Thanks,
> >
> >    David Saff
> >
> > On 1/31/07, markuspeterbaum <markuspeterbaum@...> wrote:
> > > For a long time I have been working with subversion, and now I
> tried
> > > to get back to cvs for downloading the sources for version 3.8.1.
> > > I searched on junit.org but could only find the download for 4.1.
> > > On http://sourceforge.net/project/ I found a newer version 4.2
> plus
> > > elder versions including 3.8.1. But they only contained the
> classes of
> > > the library plus some sources to test, but I need the sources of
> the
> > > framework itself. I browsed the cvs source repository, however I
> saw
> > > some tags and branches and a set of other selection mainly for
> 4.0,
> > > but I did not find any hint how to get the 3.8.1. sources
> > >
> > > Would anybody know the precise cvs repository and password - or
> else
> > > send me sources to mbjava@...?
> > >
> > > Thanks a lot for help
> > >
> > > Markus
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Vasu,

I'm sorry to be late in a reply--it's been a busy month.  The general
scenario you describe should work.  If you run class D by itself, does
everything work?  Are you running tests from the command line or
within an IDE?

    David Saff

On 1/16/07, Vasudevan Kalyanaraman <vkvasudevan@...> wrote:
> Hello David, Gabriel and other experts!
>
> Could you please help[ me with this special situation.
>
> In my company i have multiple heirarchical test suites. That is suites and sub
suites.
>
> e.g. testsuite A has test suites B C and D
> again this test suite D aggregates test suite E.
> When i execute test suite A then everything is executed.
>
> In this scenraio, the D test suite should use the Paramerized Runner and the
others use Custom Test Runner..
>
> I tried this and i am getting strange errors like "no runnable methods" for D.
>
> Is this possible ? Is there a better way choose the runner during runtime.
> Unfortunately the suite structure is a business requirement and cannot be
changed.
>
> Any help on this is appreciated...
>
> Thanks
> Vasu
>
>
> ----- Original Message ----
> From: David Saff <saff@...>
> To: junit@yahoogroups.com
> Sent: Tuesday, January 16, 2007 3:17:26 PM
> Subject: Re: [junit] Re: Custom Runner Delegation
>
> Well,
>
> I still get passing with both JUnit 4.1 and JUnit 4.2, but I am using
> the latest Eclipse milestone. I'll download 3.2.1 and try again.
>
> Actually, can you try running the below much simpler test in your
> environment? Thanks,
>
> David Saff
>
> import static org.junit.Assert. *;
> import java.lang.annotatio n.Inherited;
> import java.lang.annotatio n.Retention;
> import java.lang.annotatio n.RetentionPolic y;
> import org.junit.Test;
>
> public class InheritedAnnotation Test {
> @Retention(Retentio nPolicy.RUNTIME)
> @Inherited
> public static @interface InheritMe {}
>
> @InheritMe
> public static class Base {}
>
> public static class Sub extends Base {}
>
> @Test public void annotationIsInherit ed() {
> assertNotNull( Sub.class. getAnnotation( InheritMe. class));
> }
> }
>
> On 1/15/07, gabrielcooper <gabriel.cooper@ jtv.com> wrote:
> > > Thank you very much for that example. The mystery thickens--your test
> > > passes in my environment! (Eclipse compiler on jdk 1.5.0_04). What
> > > compiler and runtime are you using? I'm beginning to suspect
> > > differences in support for the @Inherited annotation.
> >
> > /boggle
> >
> > Windows XP
> > JUnit 4.1
> > JDK 1.5.0_06
> > Eclipse 3.2.1
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
>
>
>
________________________________________________________________________________\
____
> Be a PS3 game guru.
> Get your game face on with the latest PS3 news and previews at Yahoo! Games.
> http://videogames.yahoo.com/platform?platform=120121
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Narasimha_Tadepalli@... wrote:

> No Problem at all. But could you post me here if you have any other new
> articles on JUnit framework or Testing .

Whenever I write something new, I mention it at jbrains.ca, so you
should subscribe to my weblog to stay up to date. I'm not writing much
these days about JUnit.

Take care.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Hello, I am learning JUnit the hard way, I have inherited some code to
which I need to add some new testCases. This is in RAD 6.x, which uses
JUnit 3.8. As far as I can tell, I cannot upgrade to JUnit 4.x becuz
RAD 6.x cannot go beyond Java 1.4.2. Because I am learning, I am not
sure if my problem is with the IDE or with JUnit code - here's the
description:

The original programmer had a System.getProperty("TestPath") in his
TestAll class which extends TestCase and collects all the tests in the
TestPath directory into a TestSuite and runs them etc...

This runs but does not find the test classes, probably becuz
getTestPath() returns null : )
I cannot find where TestPath is set, created, or otherwise acquired.
When I hardcode it, the testcases are still not found. Is there a
standard for where to put and maintain the property "TestPath" in
order to run JUnit from RAD?

Thanks,
Libby

Libby,

Try giving the complete path in the "Arguments" TAB in your "run" option

Also try using the . DOT Separated path like com.rad.mycompany.test

Hope this helps,

-Kamal.
-----Original Message-----
From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
Libby
Sent: Tuesday, February 06, 2007 11:37 AM
To: junit@yahoogroups.com
Subject: [junit] Newbie Question about path to *Test.class

Hello, I am learning JUnit the hard way, I have inherited some code to
which I need to add some new testCases. This is in RAD 6.x, which uses
JUnit 3.8. As far as I can tell, I cannot upgrade to JUnit 4.x becuz
RAD 6.x cannot go beyond Java 1.4.2. Because I am learning, I am not
sure if my problem is with the IDE or with JUnit code - here's the
description:

The original programmer had a System.getProperty("TestPath") in his
TestAll class which extends TestCase and collects all the tests in the
TestPath directory into a TestSuite and runs them etc...

This runs but does not find the test classes, probably becuz
getTestPath() returns null : )
I cannot find where TestPath is set, created, or otherwise acquired.
When I hardcode it, the testcases are still not found. Is there a
standard for where to put and maintain the property "TestPath" in
order to run JUnit from RAD?

Thanks,
Libby




Yahoo! Groups Links

What is the best approach for testing private methods?

Thanks,
Gabriel


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

Hi Gabriel,

This question comes up time and again on the JUnit mailing list, and in
my opinion there is no easy answer. There are two common approaches:

01. Design. If a private method contains sufficient functionality that
you want it tested, is that a design smell? If you want to test a
private method, should it really be private?

02. Over-ride method accessibility. Use reflection to over-ride the
accessibility of the private method, and call the method indirectly.

If you think of an alternative, let me know!

Steve.

Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/

Gabriel Nascimento wrote:
>
>
> What is the best approach for testing private methods?
>
> Thanks,
> Gabriel
>
> [Non-text portions of this message have been removed]
>
>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.29/673 - Release Date: 06/02/2007
17:52

Stephen Smith wrote:
> Hi Gabriel,
>
> This question comes up time and again on the JUnit mailing list, and in
> my opinion there is no easy answer. There are two common approaches:
>
> 01. Design. If a private method contains sufficient functionality that
> you want it tested, is that a design smell? If you want to test a
> private method, should it really be private?
>
> 02. Over-ride method accessibility. Use reflection to over-ride the
> accessibility of the private method, and call the method indirectly.
>

No and no. The correct answer is

O3. Test the public methods that call the private method. Do not test
the private method directly. If no public methods call the private
method, then it isn't used and you can delete it.


--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

On 2/7/07, Elliotte Harold <elharo@...> wrote: Stephen Smith
wrote:
> > Hi Gabriel,
> >
> > This question comes up time and again on the JUnit mailing list, and in
> > my opinion there is no easy answer. There are two common approaches:
> >
> > 01. Design. If a private method contains sufficient functionality that
> > you want it tested, is that a design smell? If you want to test a
> > private method, should it really be private?
> >
> > 02. Over-ride method accessibility. Use reflection to over-ride the
> > accessibility of the private method, and call the method indirectly.

> No and no. The correct answer is

> O3. Test the public methods that call the private method. Do not test
> the private method directly. If no public methods call the private
> method, then it isn't used and you can delete it.

Here is another correct answer :-)

If it can break, it probably needs to be tested, even if it's private.

If making the method more accessible (protected, public or package) is not
an option, then feel free to set up the accessible bit, look it up with
reflection and test it like any other public method.

--
Cedric
http://testng.org


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

I put my test cases in the same logic package and changed the private
methods I wanted to test, to protected. So the test case can access it.

That´s why I think its recommended to put the test cases in another
directory, but in the same package.

The reflection will turn the coding of the unit test difficult. And the unit
tests here in the project will be used as example to the use of the API. So
it must be write as it will be used.

Thank you

On 2/7/07, Stephen Smith <steve@...> wrote:
>
>   Hi Gabriel,
>
> This question comes up time and again on the JUnit mailing list, and in
> my opinion there is no easy answer. There are two common approaches:
>
> 01. Design. If a private method contains sufficient functionality that
> you want it tested, is that a design smell? If you want to test a
> private method, should it really be private?
>
> 02. Over-ride method accessibility. Use reflection to over-ride the
> accessibility of the private method, and call the method indirectly.
>
> If you think of an alternative, let me know!
>
> Steve.
>
> Stephen Smith, MEng (Wales).
> http://www.stephen-smith.co.uk/
>
>
> Gabriel Nascimento wrote:
> >
> >
> > What is the best approach for testing private methods?
> >
> > Thanks,
> > Gabriel
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> > ----------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.17.29/673 - Release Date:
> 06/02/2007 17:52
>
>
>


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

Hi Gabriel.

As pointed out, you can either peek at the private values, make them
more visible, or just exercise the public methods that exercise the
private methods.

What's important is to understand what you are trading off with each
approach.

If you peek at privates, your tests could be more brittle, which
means they will fail more often. This could be noise, or really good
feedback depending on your circumstance. Most would say it is noisy.

If you make methods more visible, you can test them more easily, but
others can now use them more easily. You are potentially confusing
api users.

If you just exercise the public methods, then you have less brittle
tests, but you probably want to combine your testing efforts with
coverage to make sure that if you change a method to not go through a
route any more, that there is still some route with tests that cover
that behavior. Also, it could be argued that since the private is
essentially inside the public method, that you may have to do more
indirect work to get the public method to go down all the branches of
the private method. Indirection can give more flexibility, and it can
give more confusion.

Good luck,

Bob Evans
http://www.junitfactory.com/
Send Java, Get Tests


On Feb 7, 2007, at 11:26 AM, Gabriel Nascimento wrote:

> What is the best approach for testing private methods?
>
> Thanks,
> Gabriel
>
> [Non-text portions of this message have been removed]
>
>
>



Bob Evans

http://www.junitfactory.com/
Send Java code, get tests. Free.





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

--- In junit@yahoogroups.com, "Gabriel Nascimento" <gamnascimento@...>
wrote:
>
> I put my test cases in the same logic package and changed the private
> methods I wanted to test, to protected. So the test case can access
it.
>
> That´s why I think its recommended to put the test cases in another
> directory, but in the same package.
>
> The reflection will turn the coding of the unit test difficult. And
the unit
> tests here in the project will be used as example to the use of the
API. So
> it must be write as it will be used.
>

Gabriel,

I've found this article by Bill Venners to be a reasonably balanced
discussion of this topic.
     http://www.artima.com/suiterunner/private.html

Personally, as I get better at TDD with JUnit, I find that I have less
of a desire to test private methods because, for me, they come into
existence through refactoring. Since I write a test before I write the
code, and I keep one eye on my code coverage, I know that the private
methods only have tested code in them.

Regards,
Jim

So there once was a doctor.  A patient came to him and said "Doc, I have
these recurring headaches."  His response was "Well, Tylenol works."
The patient went off with the doctor's advice and, sure enough, his
headaches went away for a while.. but eventually the patient had to come
back to the doctor for something far worse.

The desire to test private method is not something that you should
ignore, it's an indication that something else is wrong.  Using
reflection to get at them is kind of like taking Tylenol without asking
what else could be wrong.

Good design is easily testable.  If you can't write test without special
tricks, it's time to go back to your design and ask: do I really have
good cohesion?  Or, why is my coupling so bad that testing is hard.

Michael Feathers
www.objectmentor.com

All,



At the Agile Open Northwest conference I held an open space session on the
future of testing tools. I expected to talk a little about Theories and
assertThat, but we ended up having a wide-ranging discussion about a variety
of topics. I mind-mapped the result and put in on the conference wiki:

http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting



The most surprising result to me was the interest in language features for
testing-what would a language look like that included double-checking as a
first-class concept? I was also surprised at how much commonality there was
between the unit and functional testing "vendors", that reporting is a big
issue for everyone.



One thing missing from the discussion was much talk about the hopes and
dreams of users, so I thought I would open up the question here. What is it
you wish your testing tool would do for you that it doesn't?



Cheers,



Kent Beck

Three Rivers Institute



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

The problem is that my domain model has an abstract class Domain with an
abstract method validate().

The subclasses of Domain implements validate, calling private methods inside
that validate its specific attributes.

I want to test each one of this attributes, but I don´t want to do this
calling the public method validate. The solution I had was to turn the
private methods to protected.

On 2/8/07, Michael Feathers <mfeathers@...> wrote:
>
>
> So there once was a doctor. A patient came to him and said "Doc, I have
> these recurring headaches." His response was "Well, Tylenol works."
> The patient went off with the doctor's advice and, sure enough, his
> headaches went away for a while.. but eventually the patient had to come
> back to the doctor for something far worse.
>
> The desire to test private method is not something that you should
> ignore, it's an indication that something else is wrong. Using
> reflection to get at them is kind of like taking Tylenol without asking
> what else could be wrong.
>
> Good design is easily testable. If you can't write test without special
> tricks, it's time to go back to your design and ask: do I really have
> good cohesion? Or, why is my coupling so bad that testing is hard.
>
> Michael Feathers
> www.objectmentor.com
>
>


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

Hi Kent,

We had a pretty good discussion around this
on this thread:

http://www.nabble.com/100---Method-Testing-and-Generating-Unit-Tests-tf2902785.h\
tml

I think we could summarize it to having a design tool
that helps design the architecture of the system,
perhaps narrowed by concern area and architectural
layer (Presentation, application, business,
integration ,data) and then generates tests that
enumerate all the corner and edge cases, helping the
designer / developer validate the system.

Personally I would like to see it combined with
something like this:

http://www.eclipse.org/articles/Article-EMF-Codegen-with-OCL/article.html

Something that generates both the application code and
the corresponding test cases.  Then makes it as simple
as possible for the users / solution recipients to
validate the system.

I'm going to summarize the thread in a little apache
licensed eclipse documentation plugin just elaborating
on the enumeration methodology, etc. discussed in the
thread.  I'll  post back when it's done.

BTW - Thanks a gazillion (To Eric as as well) for
writing "Contributing to Eclipse" and JUnit.  I think
calling it "Briliant work" would be an understatement.

Cheers,
- Ole


--- Kent Beck <kentb@...> wrote:

> All,
>
>
>
> At the Agile Open Northwest conference I held an
> open space session on the
> future of testing tools. I expected to talk a little
> about Theories and
> assertThat, but we ended up having a wide-ranging
> discussion about a variety
> of topics. I mind-mapped the result and put in on
> the conference wiki:
>
>
http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting
>
>
>
> The most surprising result to me was the interest in
> language features for
> testing-what would a language look like that
> included double-checking as a
> first-class concept? I was also surprised at how
> much commonality there was
> between the unit and functional testing "vendors",
> that reporting is a big
> issue for everyone.
>
>
>
> One thing missing from the discussion was much talk
> about the hopes and
> dreams of users, so I thought I would open up the
> question here. What is it
> you wish your testing tool would do for you that it
> doesn't?
>
>
>
> Cheers,
>
>
>
> Kent Beck
>
> Three Rivers Institute
>
>
>
> [Non-text portions of this message have been
> removed]
>
>




________________________________________________________________________________\
____
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

I noticed your map doesn't include CppUnit.  I am not surprised as
running CppUnit (Eclipse on Windows with CDT) I found it too flaky to
count on.  Is this because the group doesn't see C++ as a future
language?  It might not be.  I lobbied to use Real-Time Java instead
of C++, to no avail.  Later, when it was too late to change, the
project manager told me Java would have been a better choice.

--- In junit@yahoogroups.com, "Kent Beck" <kentb@...> wrote:
>
> All,
>
>
>
> At the Agile Open Northwest conference I held an open space session
on the
> future of testing tools. I expected to talk a little about Theories and
> assertThat, but we ended up having a wide-ranging discussion about a
variety
> of topics. I mind-mapped the result and put in on the conference wiki:
>
> http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting
>
>
>
> The most surprising result to me was the interest in language
features for
> testing-what would a language look like that included
double-checking as a
> first-class concept? I was also surprised at how much commonality
there was
> between the unit and functional testing "vendors", that reporting is
a big
> issue for everyone.
>
>
>
> One thing missing from the discussion was much talk about the hopes and
> dreams of users, so I thought I would open up the question here.
What is it
> you wish your testing tool would do for you that it doesn't?
>
>
>
> Cheers,
>
>
>
> Kent Beck
>
> Three Rivers Institute
>
>
>
> [Non-text portions of this message have been removed]
>

Gabriel Nascimento wrote:

> The problem is that my domain model has an abstract class Domain with an
> abstract method validate().
>
> The subclasses of Domain implements validate, calling private methods inside
> that validate its specific attributes.
>
> I want to test each one of this attributes, but I don´t want to do this
> calling the public method validate. The solution I had was to turn the
> private methods to protected.

In general, I dislike abstract classes, and what you describe is one of
the reasons I dislike them. If I owned the Domain class, I would do this:

1. Move the validate() method onto a new interface, called
ValidationRuleset.

2. Change Domain so that it accepts a ValidationRuleset into its
constructor.

3. Change Domain so that it invokes ValidationRuleset.validate() instead
of its own validate() method.

Now it's easy to test Domain by simulating the ValidationRuleset
interface, and it's easy to test implementations of ValidationRuleset on
their own.

One might argue that this design change makes Domain more complex, but I
disagree: it replaces an abstract method with an additional constructor
parameter. That sounds like an even trade to me, getting easier testing
as a bonus in return.

Take care.

PS: It sounds to me, based on very little information, that Domain is a
purely abstract base class, and if it looks the way I think it looks,
then it's a classic misuse of inheritance. Of course, I'm jumping to a
conclusion, so I might be wrong.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Kent Beck wrote:

> http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting
> <http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting>

This link timed out for me right now. I don't know who owns the wiki, so
I can't let them know.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Kent Beck wrote:
>
>
> All,
>
> At the Agile Open Northwest conference I held an open space session on the
> future of testing tools. I expected to talk a little about Theories and
> assertThat, but we ended up having a wide-ranging discussion about a variety
> of topics. I mind-mapped the result and put in on the conference wiki:
>
> http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting
> <http://www.agileopennorthwest.com/cgi-bin/wiki.pl?FutureOfUnitTesting>
>
> The most surprising result to me was the interest in language features for
> testing-what would a language look like that included double-checking as a
> first-class concept? I was also surprised at how much commonality there was
> between the unit and functional testing "vendors", that reporting is a big
> issue for everyone.
>
> One thing missing from the discussion was much talk about the hopes and
> dreams of users, so I thought I would open up the question here. What is it
> you wish your testing tool would do for you that it doesn't?

I'm beginning to wonder whether we should have separate design and
testing tools. This seems to be a serious source of contention among
programmers: we call it testing, but we mean design, and when we do
design, testing is a secondary consideration, and yet testing is important.

Rather than repackaging TDD and calling it BDD, hoping that Sapir-Whorf
will save us from our own sloppiness, maybe it's time for separate tools
for design and testing. I have no idea how that would work, but perhaps
it would help us all get along.

So I'd like a way to separate my design and testing activities when I do
TDD. For example, when I test-drive behavior that doesn't yet exist, I'm
almost always designing; but when I fill in the holes by adding a test
for a case that should already pass, I'm testing. Perhaps it would be
better to separate those somehow.

Any ideas?
--
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

>
> I'm beginning to wonder whether we should have separate design and
>  testing tools. This seems to be a serious source of contention among
>  programmers: we call it testing, but we mean design, and when we do
>  design, testing is a secondary consideration, and yet testing is important.
>
>  Rather than repackaging TDD and calling it BDD, hoping that Sapir-Whorf
>  will save us from our own sloppiness, maybe it's time for separate tools
>  for design and testing. I have no idea how that would work, but perhaps
>  it would help us all get along.
>
>  So I'd like a way to separate my design and testing activities when I do
>  TDD. For example, when I test-drive behavior that doesn't yet exist, I'm
>  almost always designing; but when I fill in the holes by adding a test
>  for a case that should already pass, I'm testing. Perhaps it would be
>  better to separate those somehow.

This seems elegant - I think there is a role for testing outside of
TDD. In those cases I would like automated help in generating data
(perhaps even Mocks) to test various cases. This would help test if
statements (they need to exist occaisonally), edge cases etc.
Basically I want to automate as much boiler plate stuff as I can, so
that I can focus on the design.

Cheers
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
Most Popular posts:
Scrum in a Nutshell or 5 minutes to learn Scrum
http://www.notesfromatooluser.com/2006/11/scrum_in_a_nuts.html
Getting Things Done!!! Can't Keep Track of all the tasks you have to
do? Need a better Tool to Implement GTD?
http://www.notesfromatooluser.com/2006/12/getting_things_.html

All;

In our shop, we do not do Test Driven Design (gasp!, Heretic! Burn them!
:-). So, separating test and design is all to the good. We have a well
established design methodology, and (relatively good) tool support for
design.

Where I see the biggest lack of support in testing tools is a formal,
semi-automated way to generate test stubs for requirements checking. I
would love to be able to extract from a structured requirements document
and generate a slew of test stubs for those requirements. I just got bit
in the butt today, by an untested class invariant: it was specified in
the design docs, but never implemented in the test code. (Bad Programmer
- no biscuit!)  We've been playing around with the notion of a tool to
read the structured English requirements, and automatically extract the
test stubs, but haven't had the time to make any real progress.


I agree that there are at least two large stake-holders on the JUnit
group, those who do test driven DESIGN, and those who do test driven
DEVELOPMENT, and I think that both need to be supported.

Jim
J. B. Rainsberger wrote:
>
> I'm beginning to wonder whether we should have separate design and
> testing tools. This seems to be a serious source of contention among
> programmers: we call it testing, but we mean design, and when we do
> design, testing is a secondary consideration, and yet testing is important.
>
> Rather than repackaging TDD and calling it BDD, hoping that Sapir-Whorf
> will save us from our own sloppiness, maybe it's time for separate tools
> for design and testing. I have no idea how that would work, but perhaps
> it would help us all get along.
>
> So I'd like a way to separate my design and testing activities when I do
> TDD. For example, when I test-drive behavior that doesn't yet exist, I'm
> almost always designing; but when I fill in the holes by adding a test
> for a case that should already pass, I'm testing. Perhaps it would be
> better to separate those somehow.
>
> Any ideas?
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca <http://www.jbrains.ca>
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contribution Agile Software Practice
>
>
>
> __________ NOD32 2048 (20070209) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com

--
James P. Gunderson, Ph.D.                Cognitive Systems Architect
jgunders@...                   Gamma Two, Inc.
www.gamma-two.com             		 303.778.7400
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The sad thing about artificial intelligence is that
it lacks artifice and therefore intelligence.
Jean Baudrillard,  Cool Memories, (1987, trans. 1990).

On 2/9/07, J. B. Rainsberger <jbrains762@...> wrote:
>
> So I'd like a way to separate my design and testing activities when I do
> TDD. For example, when I test-drive behavior that doesn't yet exist, I'm
> almost always designing; but when I fill in the holes by adding a test
> for a case that should already pass, I'm testing. Perhaps it would be
> better to separate those somehow.
>
> Any ideas?
>

A couple of years ago, I prototyped something (I called it Test by Example)
which you would point at a newly written class and it would construct
instances
and show you what happens when you call its methods with various inputs. It
was a tool to help you figure out the behavior of an object and identify any
unexpected behaviors. It was very useful for the kind of post-TDD testing
that you talk about but useless for huge legacy projects with lots of
inter-dependencies.

I am often struck by the distance between the discussions in lists like this
one and mainstream practice out there in Cubeland.

People such as ourselves (by which I mean people who talk about testing
ideas on mailing lists) are able to mentally partition the various goals of
testing and identify gaps and opportunities for improvement. We tend towards
a big bag o' testing tricks that we can delve into and choose the right
trick for the right goal and are always on the lookout for new tricks to add
to the bag. I suspect that mainstream development teams still have a single
bucket in their budget marked 'testing' and they are looking a for a
one-shot solution that will solve all their testing needs.

Selfishly, I'd use a tool like the one I described but I'd like to see more
tools that can gently ease developers into a test-infected frame of mind so
they can benefit from some of the other great ideas that will surely be
discussed here.

--
Kevin

http://www.junitfactory.com
You send us code. We send you tests. For free.


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