Lion-O wrote:
> Ofcourse there is a problem with discussing all this; there are many
websites
> out there which will show you the way to implement and utilize junit in
your
> own programs. But there are very few which will do so much as dive into
the
> whole philosophy behind all those tests.
The reason for this is that the philosophy is explained in "Extreme
Programming" and all the websites are assuming that you already
read this book.
> The real advantage here basically boils down to not having to write
(too) much
> code. So, instead of the authors test example:
>
> ...
> if (c.parUpToHole(0) != 0 {
> System.out.println("** Error in Course.parUpToHole: par for 0 holes
not 0");
> }
>
> if (c.parUpToHole(2) != 8 {
> System.out.println("** Error in Course.parUpToHole: par for 2 holes
not 8");
> }
> ...
>
> this code is reduced to:
>
> assertEquals(0, c.parUoToHole(0));
> assertEquals(8, c.parUoToHole(2));
>
>
> Now, granted, this is but a single example but does this really show the
JUnit
> advantage here?
No. The real advantage of JUnit is that the single testcases are executed
very fast, so while developing your code (or refactoring it) you can call
them very often and get feedback about the qualitiy of you development
very soon. It's a completely different way of developing software than
the classic one, where you implement big bunches of functionality and
try it out at the end of it.
With the ability to call these tests very often, you can see very soon
when a change in the code broke something. So finding it becomes a
piece of cake, because you only have to check the few lines of code
you changed since the last execution of the testcase.
> Lets not forget that JUnit is merely a testing framework, but
> that doesn't automatically mean or imply that unit tests can only be
done while
> using this framework.
There are a couple of othre frameworks like FIT (http://fit.c2.com/)
> After all; a unit test is merely testing to see if a
> class does as is desired. So taking the whole program used in the
example one
> could argue that a mere:
>
> public class CourseTest {
> private Course c;
>
> private static void test(int value, int result) {
> if (value != c.parUpToHole(result)} {
> System.out.println("Error in Course.parUpToHole: par for " +
result + \
> " holes not " + value);
> }
> }
>
> public static void main(String[] args) {
> c = new Course();
> c.setName("Java Course");
> int[] par = {4,4,4,4,5,4,4,3,4,4,3,4,4,5,4,4,4,4};
> c.setPar{par};
>
> test(0, 0);
> test(8, 2);
> test(72, 18);
> }
>
> } // End of class
>
>
> Personally I'm tempted not to address this small snipplet of code as a
unit
> test but merely a so called test case (see also
> http://javafaq.mine.nu/lookup?364).
So in case anyone would ask me if
I'd be
> doing unit tests I'd also tell them no. But how true is this ?
It's definately not a unit-test because unit-tests are executable
automatically. And for this two im****tant things are missing:
- You can't find out if a given class is a class belonging to
the test-suite
- You can't find out if a "test-case" actually failed. Just because
some class gives out something on STDOUT or STDERR doesn't mean
that it's a failure.
> But diving more into the matter; where is the advantage of using a
testing
> framework like junit over writing your own specific test cases
You can also ask where is the advantage of using a framework like
Ant for compiling sources and create deployable files. Of course
you can program your own stuff to checkout the sources, compile
them, create the RMI-stubs, jar everything together, sign the
Jar and transfer it using scp to the webserver. But why? Ant is
developed by a broad number of developers (same for Maven), it's
well tested and works for more or less everything.
The same is valid for JUnit. It exists for quite some time, is
well tested, integrated in more or less every IDE being available
and there are also Ant-tasks that let you execute all available
JUnit-Tests directly after compilation.
> (whether they're
> programs or merely extra debug code) ? I'm even tempted to say that
/not/ using
> a simple pre-defined framework and setting something up manually which
is also
> specific aimed at your project might even be a better solution in the
longer
> run.
It's not, because the result will be more or less the same like
JUnit or it will not work.
> So summing up; do you see any specific advantages of using a testing
framework
> like JUnit to be utilized in unit tests over writing specific testcode ?
- A proved concept
- I simply works
- It prevents you from breaking existing functionality when changing
code at a later point of time
> Personally I'm tempted (even though I haven't really dived fully into
junit
> yet) to conclude that the main advantage of JUnit is to provide a
"simple" test
> case for people who are unable (for whatever reason) to create their own
> specific testcase.
What is bad about the simple design of JUnit? Simple in the meaning
of uncomplicated doesn't mean you can only do a little number of
things. Except load- and performance-tests I test more or less every
aspect of an application.
> Going even deeper into that I'm also wondering if unit tests are really
as
> efficient as stated.
Yes they are. If you implement them during the development (the pure
doctrine says you even have to write the tests before you develop
the functionality) you don't need much longer than just implement
them (about twice the time). If a bug is re****ted, you extend the
number of testcases by one that reproduces the bug, then you fix it
and get an immediate feedback if the fix works. If you change code
at a later time, e.g. because of new requirements you see if some
of your changes break existing functionality. If you refactor your
code, you can also check easily if that breaks something. Theres
is where you save enormous amounts of time.
In addition to that you can let observe the execution of the test-
case with a coverage-tool. That way you can find out if there are
parts of the code that are not covered by the test-case. That way
you can avoid problems if the class is used in a way that is not
tested.
> What happens if the error is inside the unit itself?
All code contains bugs. But how can that be an argument against JUnit.
It's more an argument against writing your own testing-framework. Only
you yourself have to find the bugs within. JUnit is used by a bigger
number of people, so bugs already have been revealed and fixed.
> Then
> you know it has a bug, and then what?
You fix the bug in the testcase and run it again. Simple as that.
> You can then start adding debug code
> after the facts. Wouldn't it then have made more sense to add debug code
to the
> project during the development stages?
I'm not sure what you mean with that.
Regards, Lothar
--
Lothar Kimmeringer E-Mail: spamfang@[EMAIL PROTECTED]
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
|
