Junit tests, setting up tests without having to create a billion methods

Discussion in 'Java' started by xyzzy12@hotmail.com, Feb 15, 2006.

  1. Guest

    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.
     
    , Feb 15, 2006
    #1
    1. Advertising

  2. Re: Junit tests, setting up tests without having to create a billionmethods

    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, Feb 15, 2006
    #2
    1. Advertising

  3. Re: Junit tests, setting up tests without having to create a billionmethods

    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, Feb 15, 2006
    #3
  4. Re: Junit tests, setting up tests without having to create a billionmethods

    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
    >
     
    Andrew McDonagh, Feb 15, 2006
    #4
  5. James McGill Guest

    Re: Junit tests, setting up tests without having to create abillion methods

    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, Feb 15, 2006
    #5
  6. Re: Junit tests, setting up tests without having to create a billionmethods

    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
     
    Andrew McDonagh, Feb 15, 2006
    #6
  7. James McGill Guest

    Re: Junit tests, setting up tests without having to create abillion methods

    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, Feb 15, 2006
    #7
  8. Re: Junit tests, setting up tests without having to create abillion methods

    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!

    :)
     
    Andrew McDonagh, Feb 16, 2006
    #8
  9. Guest

    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;
    }
     
    , Feb 28, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Hochberg
    Replies:
    0
    Views:
    280
    Tim Hochberg
    Aug 10, 2004
  2. Subra
    Replies:
    25
    Views:
    1,256
    user923005
    Mar 8, 2007
  3. CMOS
    Replies:
    2
    Views:
    500
    Zeppe
    May 17, 2007
  4. Sullivan WxPyQtKinter
    Replies:
    18
    Views:
    590
    John J. Lee
    Aug 12, 2007
  5. Rhino
    Replies:
    3
    Views:
    644
    Tom Anderson
    May 19, 2010
Loading...

Share This Page