I don't like Junit.....

ankur rathi

Ranch Hand

Posts: 3830

posted 12 years ago

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...

"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.

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

Posts: 14112

posted 12 years ago

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.

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

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.

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

Thomas Paul

mister krabs
Ranch Hand

Posts: 13974

posted 12 years ago

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.

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...

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

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.

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.

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

posted 12 years ago

Originally posted by peter wooster: you could include them in your daily build.[/QB]

Or even better, in your hourly build.

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

Lasse Koskela

author
Sheriff

Posts: 11962

5

posted 12 years ago

Originally posted by Ilja Preuss: Or even better, in your hourly build.

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...

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

peter wooster

Ranch Hand

Posts: 1033

posted 12 years ago

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.

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.