• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JB: How expensive is JUnit testing...?

 
Ranch Hand
Posts: 235
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The basic guidelines of JUnit test writing were explained to me as:

The software does well those things that the tests check.
Test a little, code a little, test a little, code a little...
Make sure all tests always run at 100%.
Run all the tests in the system at least once per day (or night).
Write tests for the areas of code with the highest probability of breakage.
Write tests that have the highest possible return on your testing investment.
If you find yourself debugging using System.out.println(), write a test to automatically check the result instead.
When a bug is reported, write a test to expose the bug.
The next time someone asks you for help debugging, help them write a test.
Write unit tests before writing the code and only write new code when a test is failing.


I've got to say that adding all these steps is going to add some considerable development time. I realize that JUnit actually helps us out, but how do we sell to our managers the benefits, when they will only see the number of additional hours that we tack onto dev time in order to complete a assignment?

Thanks,
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael,
You can choose whether you want to test or code first. I like testing first (TDD), but not everyone on my team does that. It's ok as long as the tests get written. Other than that, I agree with all the guidelines you wrote. I would add one which is to run all the tests before checking in code to the repository.

It doesn't add as much time as you think. There is the initial learning curve, but after that it evens out. You still have to think about your code and test it in some way (like by hand) anyway. Long run, you also have to spend a lot of time chasing down those elusive bugs that you could have found if you use junit.

when they will only see the number of additional hours that we tack onto dev time in order to complete a assignment?


The first thing you can do is start doing it in your spare time. If you start by testing a few classes, the time impact is very small. After a while, you can show them that it helped by reducing the bug count. (Maybe list a few bugs that you aren't reintroducing. This works well if you write tests for a particularly problematic class.)

Also, don't present it as a separate activity. On my team, we treat testing as an essential activity. Every time my manager asked me how long it would take to code and then how long to test, I gave him one number. After all, I would have to test by hand anyway. I justify this in that it doesn't make sense to have code that we don't know if it works. By now, nobody asks for separate estimates anymore.

Just so you know, I found it trickier to get coworker buy-in than management buy-in.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael Sullivan:

I've got to say that adding all these steps is going to add some considerable development time.

I actually disagree with this statement. I think they add to coding time, but subtract from debugging time. The net effect on total development time is often that it's shorter, depending on the complexity and size of the system.

The question about how to convince management is valid, though. I think getting permission to use it on a pilot basis is a good start. Then after they see that total productivity is up, or at least not down, they'll be convinced.
 
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Michael:

Like any other new skill, learning to write these tests takes time. However, once you get past the learning curve, our experience shows that writing tests helps us make steady, good progress. The result is fewer defects to the Testing team (saves time), to the customers (saves time and embarrassment), a more maintainable design (saves time on future releases)... the amount of time programmer testing saves far outweights the investment in learning the skill.

The problem is that your managers may be optimizing too small a part of the process. They may continue to pretend that coding, testing and maintenance should be separate phases of a project, rather than ongoing, concurrent activities.
 
Ranch Hand
Posts: 1312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by J. B. Rainsberger:
Michael:

Like any other new skill, learning to write these tests takes time. However, once you get past the learning curve, our experience shows that writing tests helps us make steady, good progress. The result is fewer defects to the Testing team (saves time), to the customers (saves time and embarrassment), a more maintainable design (saves time on future releases)... the amount of time programmer testing saves far outweights the investment in learning the skill.

The problem is that your managers may be optimizing too small a part of the process. They may continue to pretend that coding, testing and maintenance should be separate phases of a project, rather than ongoing, concurrent activities.




So, this is SAVE Time for developement application but IS NOT SAVE COST for development application OR NOT ???

Because , In project MUST Have Testing Team (This is cost).


 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by somkiat puisungnoen:
So, this is SAVE Time for developement application but IS NOT SAVE COST for development application OR NOT ???

Because , In project MUST Have Testing Team (This is cost).


Yes, you must have a testing team but the amount of work they have to do should be reduced significantly if you can eliminate errors before they are thrown over the wall to the testing team.

Having the test team find a defect costs a lot more than having the programmer find the same defect during development. It's as simple as that.
 
J. B. Rainsberger
author
Posts: 87
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While learning to write tests, you might actually spend more than you usually do during coding, but you will save some of that during testing.

After you have mastered the basics, you will go faster during coding and faster during testing.

After you have mastered the stuff in JUnit Recipes part 2, you will go much faster during coding and faster during testing.

After that, you're always making a profit on time and effort. ALWAYS.

Would you invest $100k to be paid $1M per year the rest of your life?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The problem is that your managers may be optimizing too small a part of the process. They may continue to pretend that coding, testing and maintenance should be separate phases of a project, rather than ongoing, concurrent activities.


Speaking of phases, if there are major problems upstream (requirements, analysis, design), junit will not solve them.

Yes, you must have a testing team but the amount of work they have to do should be reduced significantly if you can eliminate errors before they are thrown over the wall to the testing team.


That wall is another problem. If the testing team and development team have different reporting/budget structures, the development manager will not care that you are reducing the amount of work for the testing team. That's why it is necessary to point out the reduction in re-work and deployments for the development team.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
That wall is another problem.

Yes, it is. A big problem.

Originally posted by Jeanne Boyarsky:
If the testing team and development team have different reporting/budget structures, the development manager will not care that you are reducing the amount of work for the testing team.


Ah. My current environment is a bit different. We have a dedicated functional testing team which works based on the use case documents the development team provides them. When I joined the project, things had already improved a lot from what it was some time ago. These two teams have a single project manager, a single goal (to get the release out on time, tested), and thus it's no problem to convince the team about the importance of reducing the work load of the testing team (which has a history of being the bottleneck when the release date comes close).
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lasse,

These two teams have a single project manager, a single goal (to get the release out on time, tested)


How does that not create a conflict of interest? The testers want to find bugs and the developers want to get the project out. What is the project manager evaluated on? Time? Quality without time? Both?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
How does that not create a conflict of interest? The testers want to find bugs and the developers want to get the project out. What is the project manager evaluated on? Time? Quality without time? Both?


The testers don't want to find bugs. They want to verify that the software works. They're not rewarded on the number of bugs found. The project manager, which is a consultant as well, is evaluated on customer satisfaction. Customer satisfaction comes from the project meeting its milestones on time (which is a bit of a problem).
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The testers don't want to find bugs.


I always thought that QA tries to "break the code." Granted my sample is small, but I have heard a couple people say that. I guess if QA looks at is as trying to make sure the code functions properly, that would work too.

I didn't mean to imply that the test team would be measured by the number of bugs they found. That definitely wouldn't work as a test team would be at a disadvantage if the developers gave them a clean product.
 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Testing serves more than one purpose. First, unit tests can more or less express the requirements of your projects. In theory, you should be able to write a bunch of tests, covering the entire scope of the project. After implementing the code that makes all the tests pass, your project should be finished. In this perspective, test-first programming makes you write only the necessary code, so you won't write one line of code too much, and you wont write an untested line of code. In real life, you should try to get as close to this theory as possible... So, this first point is more like a methodology, and not so much a time saving solution.

Second, writing tests for you classes really avoids a lot of bugs. And you will probarbly know, the later you find a bug, the more it will cost to fix it.

Third, and if you ask me, the most interesting point of all, testing your code gives you a huge advantage during refactoring or rewriting your code. Changing one little piece of code can make an onther (totaly different) piece of code not work properly anymore. And this happens a lot! Your tests will instantly point out the places where problems might occur. And this is definately a time saver!

So, writing tests will not be something that you have to sell to your customer. It will give you a methodology to write flexible quality code (i.e. more flexible and less bugs than untested code). It will help you to translate your use cases/user stories in code and will save a lot of time when exisiting code is refactored, rewritten or even extended.

Greets,
Kris
[ September 05, 2004: Message edited by: Kris Philippaerts ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic