File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Testing and the fly likes I don't like Junit..... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "I don Watch "I don New topic
Author

I don't like Junit.....

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Does you all guys/gals also make test method for each public method (except getter and setter method)??? I feel, it is just waste of time. I mean, you can assume how much time it takes to hard code any *big* object (expected result) and then for comparing actual and expected result, either you iterate it or override its equals() method, both takes time. It just overkilled to write test method for each and every public method...

What you guys/gals think???

Is there any work around for this???

Thanks a lot for your time.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8903

I dont write any test for get/set methods.


Groovy
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by rathi ji:

What you guys/gals think???


You can spend time testing up front, or you can spend time debugging later. Your choice. I like writing tests better. Takes less time, too.


[Jess in Action][AskingGoodQuestions]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
"Write a unit test for all public methods" is not a good rule, in my opinion. I'd much rather follow common sense and test those methods (or combinations of methods!) that I feel to be worth the effort.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
There is a good rule in "JUnit Recipes": "Don't test methods, test behaviour."


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by rathi ji:

Is there any work around for this???


Doesn't this question mean that you don't know a better way to get quality software? So how can you say that it is overkill?

If you want to know wether your code works, you need to test it. If you want to know wether tomorrow, when you needed to change the code, you didn't break something, you need to test it again. As you need to do the day after tomorrow and so on. The cheapest way I know of to do that is to automate the tests.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30050
    
149

Rathi,
You can save some time by putting the common code in a method. We wrote some custom assertions to compare for equality using refelection and to compare two Collections of objects. This saves time when writing individual tests and makes it less tedious.

"Don't test methods, test behaviour." - Definitely! But if a method doesn't reflect behavior, what is it there for? You still wind up testing all the methods, even if you don't look at it from that point of view.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:
You still wind up testing all the methods, even if you don't look at it from that point of view.


That's true! After all, if we don't care whether (!) a method works, why write it...
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
I'm with Lasse on this one. And if you have been using an IDE, your setters and getters have probably been generated for you. If they don't work then there is something much more seriously wrong than a bug in your code.

of course, one could argue that getters and setters are a bad idea anyway since they don't reflect behavior but rather state.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I wouldn't test accessor *directly*, either. I'd suppose they are used from other tested code, so they'd get enough test coverage from those tests. (Until I get my first bug in an accessor because of a missing test, I guess...

And I fully agree with Thomas, by the way - especially with getters and setters often not being the optimal design solution...
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30050
    
149

I agree with Thomas too. I would never write a test directly for a generated getter or setter. According to our code coverage tool, the getters and setters do get tested by virtue of the other tests existing. And when they don't it often signifies a bug because someone forgot to use that member.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Jeanne Boyarsky:
I agree with Thomas too. I would never write a test directly for a generated getter or setter. According to our code coverage tool, the getters and setters do get tested by virtue of the other tests existing. And when they don't it often signifies a bug because someone forgot to use that member.


I agree, getters and setters should be tested by actual use.

Coverage is the answer, no matter how you design your unit and regression tests, if they don't cover your code you will be leaving areas untested.

My approach is to start with behavioural tests, build scripts or JUnit tests and use a coverage tool like Clover or Emma to track the level of coverage. When the level of coverage reaches about 80%, I examine all the untested code and determine if its actualy needed, you will be surprised what you find. I then comment the untest code as untested, so its obvious to anyone later chasing a bug or attempting to increase the coverage level.

Any time the code is changed, I rerun the tests as part of the build process, you could include them in your daily build.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by peter wooster:
you could include them in your daily build.[/QB]


Or even better, in your hourly build.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
Or even better, in your hourly build.

Why wait for so long?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:

Why wait for so long?


Because our build takes an hour. I know, it's not optimal, and I already have some ideas for optimizations, but it's still better than what we had some months ago.

Doesn't have Kent Beck a "ten minute build rule" in the second edition? I like it - it's certainly the time span I'd prefer...
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Ilja Preuss:

Because our build takes an hour. I know, it's not optimal, and I already have some ideas for optimizations, but it's still better than what we had some months ago.

Doesn't have Kent Beck a "ten minute build rule" in the second edition? I like it - it's certainly the time span I'd prefer...


Back in the eldar days I worked on a very large 360 Assembler project where you had to do a full build and run your tests every time you changed the code. I was one of the few people back then doing coverage tests, but they took far longer than 1 hour. We tended to go for a few beers while they ran.

This is why I suggested putting them in your daily build instead of running them every time you changed anything. I still prefer the latter.

Even now unit and coverage tests can take a long time, last time I ran the tests on POI it took about 20 minutes, time to quaff a couple.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Ilja Preuss:


Because our build takes an hour.


It sucks, doesn't it. On one of my projects, our unit test suite (18,000 tests, now) takes about 400 seconds to run. It's been optimized, and re-optimized, and optimized again. That is one tight code base. There's pretty much nothing left to do to speed things up.

It's no longer possible to run all the tests after every change, so now I'll run only appropriate subsystem tests while I'm working, and run the whole unit test suite just before a checkin. I'd prefer to check in more often, but with 400 seconds of unit tests, I find myself staying "out" for an hour or so at a time.

And don't get me started on the application tests; they take over three hours. Those we just run overnight.
 
wood burning stoves
 
subject: I don't like Junit.....
 
Similar Threads
assertNotSame pRmeters
The time has come, what u are doing?
Overloaded method call
A question for all those who returned to India...
Designing a class and test program