aspose file tools*
The moose likes Testing and the fly likes To All.. The most common mistake we do when using JUnit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "To All.. The most common mistake we do when using JUnit" Watch "To All.. The most common mistake we do when using JUnit" New topic
Author

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

Andres Gonzalez
Ranch Hand

Joined: Nov 27, 2001
Posts: 1561
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'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
Vincent Massol
Author
Ranch Hand

Joined: Aug 09, 2003
Posts: 70
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.


-Vincent<br /><a href="http://www.manning.com/massol" target="_blank" rel="nofollow">JUnit in Action</a> author
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
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

Joined: Mar 06, 2001
Posts: 1209
pretty basic. C'd asserting against a hardcoded value be considered one of the mistakes?.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Qusay Jaafar
Ranch Hand

Joined: May 06, 2002
Posts: 127
I believe only one test for one task.


Qusay
Vincent Massol
Author
Ranch Hand

Joined: Aug 09, 2003
Posts: 70
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

Joined: Apr 23, 2002
Posts: 168
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

Joined: Apr 23, 2002
Posts: 168
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

Joined: Mar 06, 2001
Posts: 1209
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

Joined: Mar 06, 2001
Posts: 1209
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 :-))
 
 
subject: To All.. The most common mistake we do when using JUnit