UnitTesting

[Graham Thorpe]

Can any body give good concept about UnitTesting..
What is the need of Unittesting ?
and when it will applicaple this UnitTesting?
Is it same as Untitesting and CompileTesting i mean javac filename.java?

[Barry Gaunt]

For background info look at the documentation at http://www.junit.org/
in particular: here.
[ January 15, 2003: Message edited by: Barry Gaunt ]
This too from your very own JavaRanch News Letter
[ January 15, 2003: Message edited by: Barry Gaunt ]

[Wilfried LAURENT]

What is the need for unit testing?
Identifying bugs early on in the development cycle. As you probably know, the later you find a bug, the more expensive it is.
It also provides a repartition of the test effort before integration effort. Unit testing lets you test a ... unit of program -that is a mostly a class- and verify if the results conforms to what was expected. This gives a binary answer: Success of failure.
Then later on, if you change something in the implementation of your class, just run the unit test. If it still succeeds, then you can confidently deliver your class.
There is an abondant litterature on unit testing on the Web, junit.org for example.
W.

[Ilja Preuss]

http://c2.com/cgi/wiki?UnitTest and linked pages contain some interesting information on the subject.

[Graham Thorpe]

Hi
I didnt get the good points from www.junit.org website.Thats why i posting my question here about Junit.What the exact definition of UnitTesting interms of SoftwareEngineering.And when it will applicable.And how can i proceed unittesting with my small HelloWorld java file.

[Graham Thorpe]

is it availble any Unittesting software except Junit!!if yes please refer me

[Ilja Preuss]

Originally posted by glkrr reddy:
What the exact definition of UnitTesting interms of SoftwareEngineering.

I don't think you will get a more exact definition everyone will agree to than "testing single units of a system, in contrast to testing the system as a whole."

And when it will applicable.

Well, almost always, as soon as you start to write the first lines of your code.

And how can i proceed unittesting with my small HelloWorld java file.

Well, I wouldn't unit test a HelloWorld file - there isn't something which could go wrong once it compiles, I would think. It would be possible, though - if you want, we could do a quick example.
You might also want to take a look at the following thread: https://coderanch.com/t/97611/patterns/OO-Calculator-Tutorial - it's about developing a calculator including intensive unit testing.

[Frank Carver]

Well, I wouldn't unit test a HelloWorld file - there isn't something which could go wrong once it compiles.
However, I would unit test my "ability to compile and run" before I write the HelloWorld! I almost always start each new project with the following file:

package tests;
import junit.framework.*;
 
public class EmptyTest extends TestCase
{
  public void setUp()
  {
  }
  
  public void testEmpty()
  {
  }
}

It does nothing. But that's the point.
If I can get this code to compile and run, I am confident of my abilities to compile and run something more complex (like a "Hello World" example). After I have compiled and run this simple test (and got a "1 test passed" message, I know that any future failures will entirely be due to the absence of code I haven't written yet or faults I introduce while writing or changing code. I never need to think "it might be a problem in my code, or it might be a compiler or JVM environment problem".
And by including this test in a test suite that I re-run after every change, I know that if the build environment does break then this test will tell me immediately I try to run it.
To me, this is a simple example of why unit testing is such a powerful technique. It enables me to separate (and thus eliminate) my worries. With a well-chosen set of unit tests there should never be any need to hunt for bugs. Just looking at which tests have passed and which have failed should be enough to pinpoint the location of the problem straight away.

[Reid M. Pinchback]

The wiki page mentioned above is useful, but I'll try to add my two cents in.
A "unit" means whatever you want it to mean, but that places the onus on you (or your organization) to decide what it is you hope to get from your testing.
For example, "unit" to NASA or for some defense project would be a very big thing. It is really tied to a contract. Different contractors supply different components that will be assembled into a whole system. Those firms may not even know what the whole looks like. When the components arrive, they are "unit tested" to see if they meet their specs. For large granularity like this, unit test = IV&V, which is an expensive process.
Compare that to a Java programmer. They'll be faced with deciding on what a unit is... an application, a package, a class, a method being the obvious candidates. How to choose?
Testing is a divide-and-conquer problem. Testing a big thing is hard, so you try to test a bunch of small things. You'll pick the "unit" that suits your work.
If you were part of a project to create a large application suite, a single app or a shared DLL is probably going to be viewed as a unit.
If instead you are working on some large J2EE app with a strong "business component" mindset, than a single EJB (particularly the session beans) might be a unit.
When all is said and done, I believe it is a game of managing complexity versus cost. Complexity metrics for software make it pretty clear that effectively testing big things is very difficult. The smaller you can make your unit, the easier it is to convince yourself that testing is "done" and the unit works. The downside is that as the unit size shrinks, you write more tests and hence the total testing cost tends to grow.
Of course those tests get easier to write, so practically you can make your unit tests pretty small without a lot of overhead. The danger is more in system evolution events. When you change something, you may find a lot of tests break, and you have to decide what those breaks mean. The smaller the unit size, the more broken tests you have to examine. If you read some of the articles on the JUnit site, you'll see mention of the fact that unit tests shouldn't be a straight-jacket. I think this is the kind of problem being referred to.