The Artima Developer Community
Sponsored Link

Java Community News
JUnit Reloaded

6 replies on 1 page. Most recent reply: Dec 31, 2006 12:32 AM by Martin Ankerl

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 6 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

JUnit Reloaded Posted: Dec 28, 2006 1:55 PM
Reply to this message Reply
Summary
In a recent article on java.net, Ralph Stuckert provides a tour of JUnit 4, the new incarnation that uses annotations extensively. What's your opinion of the new JUnit design?
Advertisement

In JUnit Reloaded, author Ralph Stuckert describes the new JUnit. The highlights are:

  • Test classes no longer need extend TestCase
  • Test methods need no longer start with "test"; Instead, they must be annotated with "@Test"
  • To use the assert* methods directly, add a static import of org.junit.Assert
  • setUp and tearDown methods can have any name but must be annotated with @Before and @After
  • Static methods annotated with @BeforeClass and @AfterClass are run before and after all the test methods in that class
  • You can specify a timeout for a test in the @Test annotation, after which the test will automatically fail
  • You can indicate an exception to expect in the @Test annotation
  • You can indicate a test method should be ignored with an @Ignore annotation
  • You use annotations to build suites

What's your opinion of JUnit 4's approach? Do you think it will it make your job easier? What's missing?


Martin Ankerl

Posts: 9
Nickname: sunitram
Registered: Mar, 2005

Re: JUnit Reloaded Posted: Dec 29, 2006 1:16 AM
Reply to this message Reply
I like the new annotations, but I really dislike the approach they did with the assert-statements. For a project I work on I am writing a library that can be used as a replacement for the assertations, with an interface like that:


int x = 10;
ensure(i).between(8, 20);

Integer[] a = { 1, 2, 3, 4, 5, 6 };
ensure(a).size().is(6);
ensure(a).isUnique();
ensure(a).isSorted();


ensure () returns a different Checker object that is customized to the type you want to have checked. E.g. for collections you have different checks available than for numbers. The nice feature about this interface is that it can be easily extended. Whenever I need a new check I try to write it in a more generalized way and add it to the library so that I can reuse it later.

Parag Shah

Posts: 24
Nickname: parags
Registered: Mar, 2003

Re: JUnit Reloaded Posted: Dec 29, 2006 2:06 AM
Reply to this message Reply
I like the addition of being able to indicate an Exception that is expected. Earlier I used to write tests that expected an Exception and fail the test explicitly if it was not thrown. The new appraoch is a lot cleaner.

With annotations we can write the test code inside the class that is being tested. No need to create a new class. I'm still not sure if this is a good idea. It might make the class very bulky, but at the same time it might be a benefit while doing TDD, since we will not have to switch between classes. I'm wondering if it is possible to write build scripts that will igore the test code from a pruduction build.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: JUnit Reloaded Posted: Dec 29, 2006 9:36 AM
Reply to this message Reply
> I like the new annotations, but I really dislike the
> approach they did with the assert-statements. For a
> project I work on I am writing a library that can be used
> as a replacement for the assertations, with an interface
> like that:
>
>
> int x = 10;
> ensure(i).between(8, 20);
>
> Integer[] a = { 1, 2, 3, 4, 5, 6 };
> ensure(a).size().is(6);
> ensure(a).isUnique();
> ensure(a).isSorted();

>
> ensure() returns a different Checker object that is
> customized to the type you want to have checked. E.g. for
> collections you have different checks available than for
> numbers. The nice feature about this interface is that it
> can be easily extended. Whenever I need a new check I try
> to write it in a more generalized way and add it to the
> library so that I can reuse it later.
>
That's interesting. What's the interface to Checker?

Martin Ankerl

Posts: 9
Nickname: sunitram
Registered: Mar, 2005

Re: JUnit Reloaded Posted: Dec 29, 2006 10:16 AM
Reply to this message Reply
> That's interesting. What's the interface to
> Checker?

I have different types of Checkers, e.g. a CollectionChecker, a NumberChecker, ObjectChecker etc. ensure() is a static method that is overloaded for each of the different checkers, e.g. ensure(Collection c), ensure(Number n), etc. The nice thing is that this way you need just one static import to be able to access all these methods. Another nice feature is that the different checkers can use each other, for example:

ensure(array).size().is(5)

Here ensure(array) returns an CollectionChecker, the call to size() returns a NumberChecker which in turn has the is() method to do the actual verification and throws an Exception in case of an error. This way you can do pretty cool things, e.g. I have written a statistical checker that uses confidence intervals to verify e.g. a heuristic optimizer can return a solution close enough to the optimium in 95% of the cases.

David Saff

Posts: 9
Nickname: dsaff
Registered: Nov, 2005

Re: JUnit Reloaded Posted: Dec 30, 2006 5:55 PM
Reply to this message Reply
How would you compare your checker interface to the assertThat interface pioneered by Joe Walnes?

Martin Ankerl

Posts: 9
Nickname: sunitram
Registered: Mar, 2005

Re: JUnit Reloaded Posted: Dec 31, 2006 12:32 AM
Reply to this message Reply
assertThat is probably more mathematically corect, you can do boolean operations with not() and or() which you cannot do with ensure(). With ensure() you are more at the mercy of the writer of the checkers, you cannot combine constraints yourself.

With ensure() code completion works, when you write "ensure(5)." you get a list of all the possible checks for numbers.

You cannot create nonsense statements with ensure(). with assertThat() you can write assertThat("asdf", between(10, 11)); (disclaimer: I have not tested this) and it will compile. Thats not possible in ensure(), you get only the methods that will make sense.

Last but not least, I think ensure() is much easier to read and use. I wanted something that is as simple to use as possible, even at the expense of flexibility. ensure() statements almost look like English sentences (disclaimer: my native language is German :-)

Flat View: This topic has 6 replies on 1 page
Topic: Groovy 1.0 Released Previous Topic   Next Topic Topic: Databases: Not Just For Storing Data

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use