Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

To All.. The most common mistake we do when using JUnit

 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think is "catching exceptions". based on my experience, I've seen hundreds of lines of code with that. JUnit should take care of that!
any other mistakes you've seen?
 
Vincent Massol
Author
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andres Gonzalez:
I think is "catching exceptions". based on my experience, I've seen hundreds of lines of code with that. JUnit should take care of that!
any other mistakes you've seen?

I completely concur.
Another one is trying to test two many things in one test (testXXX method).
Another one is too big test methods where people write 200 lines of setup code before calling the code under test. This is a code smell. The code under test probably badly need a refactoring, probably to split it into several methods/objects.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vincent Massol:

Another one is too big test methods where people write 200 lines of setup code before calling the code under test.

do you mean some beginABC() method that has lots of parameters set in the webRequest?

we have tons of such parameters that needs to be set to test the functionality ( say createXXX). I wonder if developers s'd be writing unit tests at all for such things? S'd such tests be written using tools like winrunner etc?
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
pretty basic. C'd asserting against a hardcoded value be considered one of the mistakes?.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
C'd asserting against a hardcoded value be considered one of the mistakes?.
Depends on whether the hardcoded value is considered duplication and whether the reason for that particular value is located somewhere else or right next to the hardcoded value.
 
Qusay Jaafar
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe only one test for one task.
 
Vincent Massol
Author
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by karthik Guru:

we have tons of such parameters that needs to be set to test the functionality ( say createXXX). I wonder if developers s'd be writing unit tests at all for such things? S'd such tests be written using tools like winrunner etc?

I was not talking about Cactus. I was talking about code that is not well designed and thus requires huge fixture code to test it.
 
Michael Zalewski
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by karthik Guru:
[QB]

Perhaps you could consider making a fixture

Once you have that, you can make your test methods concentrate on the differences between each test, instead of always adding the same parameters for each test.
You might also consider working on class FixWebRequest so it can take a querystring

But a warning: don't try to make the fixture too smart. You want to concentrate on writing test methods, not implementing behavior in the fixtures.
 
Michael Zalewski
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have two mistakes beginners make when using JUnit:
1) trying to build state into the testcase. It's really hard to do that, because JUnit has a classloader that will clear out your test case class for every test. It will even clear out the static fields.
2) forget to test methods in a superclass. You need to use judgement, because this is not always necessary. But for example, suppose a base class implements Comparable. The base class depends on the behavior of such things as equals(), hashCode(), compareTo(). These probably should be tested in each subclass.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Michael, But I can tell you that the set up looks pretty messy in our case. I mean each of the workflows require as many Fixtures that you demonstrated sine the parameters expected in the request are different.
I will figuring out as to how the query string thing that you suggested works. But developers here hate it :-)
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vincent Massol:

I was not talking about Cactus. I was talking about code that is not well designed and thus requires huge fixture code to test it.

oh no infact my question was:
If there are tons of things being set up in the webRequest , s'd i view that with suspicion? I mean s'd a *developer* be writing tests for such a functionality? S'd'nt a functional testing tool be doing the job instead?
(they make us write such tests here :-))
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic