• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

I don't like Junit.....

 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont write any test for get/set methods.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a good rule in "JUnit Recipes": "Don't test methods, test behaviour."
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author & internet detective
Marshal
Posts: 34229
341
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13974
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author & internet detective
Marshal
Posts: 34229
341
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Or even better, in your hourly build.

Why wait for so long?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic