Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > unit testing guidelines

Reply
Thread Tools

unit testing guidelines

 
 
Jacob
Guest
Posts: n/a
 
      03-17-2006
I have compiled a set og unit testing
recommendations based on my own experience
on the concept.

Feedback and suggestions for improvements
are appreciated:

http://geosoft.no/development/unittesting.html

Thanks.
 
Reply With Quote
 
 
 
 
Hendrik Maryns
Guest
Posts: n/a
 
      03-18-2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Jacob uitte de volgende tekst op 03/18/2006 12:03 AM:
> I have compiled a set og unit testing
> recommendations based on my own experience
> on the concept.
>
> Feedback and suggestions for improvements
> are appreciated:
>
> http://geosoft.no/development/unittesting.html


Nice work.

I don't totally agree with point 16: a throws statement means an
exception *might* be thrown, and the circumstances under which this can
happen should be documented. It is seldom that an exception must be thrown.

You might want to give some explanation about what you assertX methods do.

H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD4DBQFEHEUxe+7xMGD3itQRAsFwAKCBXX77fVjeMGJz3+AU0B xe/pYnoQCY5z2F
Ti5C4PCNnHJBSHbz3tp2jQ==
=VsD2
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      03-18-2006
In article <dvhgcf$opd$03$(E-Mail Removed)-online.com>,
Hendrik Maryns <(E-Mail Removed)> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
>
> Jacob uitte de volgende tekst op 03/18/2006 12:03 AM:
> > I have compiled a set og unit testing
> > recommendations based on my own experience
> > on the concept.
> >
> > Feedback and suggestions for improvements
> > are appreciated:
> >
> > http://geosoft.no/development/unittesting.html

>
> Nice work.
>
> I don't totally agree with point 16: a throws statement means an
> exception *might* be thrown, and the circumstances under which this can
> happen should be documented. It is seldom that an exception must be thrown.


I agree. Only test what you actually want the client code to rely on.
Now if you want the client code to rely on the method throwing an
exception...


--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-18-2006
Jacob wrote:
> I have compiled a set og unit testing
> recommendations based on my own experience
> on the concept.
>
> Feedback and suggestions for improvements
> are appreciated:
>
> http://geosoft.no/development/unittesting.html
>

I'd add point 0 - write the tests first.

8 - names should be more expressive, rather than testSaveAs(), how about
a series of tests, testSaveAsCreatesANewFile(),
testSaveAsSavesCuentdataInNewFile() etc. Often tests with a broad name
attempt to test too much ad don't express their intent.

Point 0 covers point 11.

13 - take care with random numbers, they can lead to failures that are
hard to reproduce. I'd use a pseudo-random sequence that is repeatable
with a given seed.

0 and 8 covers 14.

0 covers 17.

0 covers 20.

--
Ian Collins.
 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      03-18-2006
Jacob schrieb:
> I have compiled a set og unit testing
> recommendations based on my own experience
> on the concept.
>
> Feedback and suggestions for improvements
> are appreciated:



| 7. Keep tests close to the class being tested
|
| If the class to test is Foo the test class should be called FooTest
| and kept in the same package (directory) as Foo. The build environment
| must be configured so that the test classes doesn't make its way into
| production code.

It is necessary to have test classes in the same package as the tested
class in order to test package private methods.

But you don't have to put the classes in the same directory. Most IDEs
support several source folders. You can setup two source folders. For
example: "src" for your application source, "test" for your test source.
If you use the same package structure in the test source folder, you can
test package private methods and it is very easy to deploy only
application code.


Timo
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      03-18-2006
Timo Stamm wrote:
> Jacob schrieb:
>
>> I have compiled a set og unit testing
>> recommendations based on my own experience
>> on the concept.
>>
>> Feedback and suggestions for improvements
>> are appreciated:

>
>
>
> | 7. Keep tests close to the class being tested
> |
> | If the class to test is Foo the test class should be called FooTest
> | and kept in the same package (directory) as Foo. The build environment
> | must be configured so that the test classes doesn't make its way into
> | production code.
>
> It is necessary to have test classes in the same package as the tested
> class in order to test package private methods.
>

Another view that tests that require access to private methods are a
design smell. Often these can be refactored into objects that can be
tested in isolation.

In C++, it's very tempting to make the test class a friend of the class
under test. I've found that I end up with a better design by resisting
this temptation.

--
Ian Collins.
 
Reply With Quote
 
Hendrik Maryns
Guest
Posts: n/a
 
      03-18-2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Ian Collins uitte de volgende tekst op 03/19/2006 12:13 AM:
> Timo Stamm wrote:
>> Jacob schrieb:
>>
>>> I have compiled a set og unit testing
>>> recommendations based on my own experience
>>> on the concept.
>>>
>>> Feedback and suggestions for improvements
>>> are appreciated:

>>
>>
>>
>> | 7. Keep tests close to the class being tested
>> |
>> | If the class to test is Foo the test class should be called FooTest
>> | and kept in the same package (directory) as Foo. The build environment
>> | must be configured so that the test classes doesn't make its way into
>> | production code.
>>
>> It is necessary to have test classes in the same package as the tested
>> class in order to test package private methods.
>>

> Another view that tests that require access to private methods are a
> design smell. Often these can be refactored into objects that can be
> tested in isolation.


I was about to answer the same: shouldn't problems in package private
methods spill through to public methods? Then why test them separately?
Find an error in a public method and retrace it with you favorite
debugger to the package private method, I'd say (without much
experience, so correct me if I'm wrong).

H.

--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEHJyze+7xMGD3itQRAuV5AJ9RMb89yiGxxknFqT7XCa TjHnJJ9QCfXrZ3
7iuZP99HYR0uR9FuffXLeLk=
=KKUv
-----END PGP SIGNATURE-----
 
Reply With Quote
 
Bent C Dalager
Guest
Posts: n/a
 
      03-19-2006
In article <dvi687$bgi$03$(E-Mail Removed)-online.com>,
Hendrik Maryns <(E-Mail Removed)> wrote:
>
>I was about to answer the same: shouldn't problems in package private
>methods spill through to public methods? Then why test them separately?


It makes it more time-consuming to find out where the error is.

> Find an error in a public method and retrace it with you favorite
>debugger to the package private method, I'd say (without much
>experience, so correct me if I'm wrong).


I prefer my unit tests to have obvious failure modes so that I can
basically tell from which test failed, exactly where in my source the
bug is. This means I don't have to muck around with a debugger, I can
just fix it and get on with things.

For this to be the case, however, the methods that I test need to be
reasonably small and not do a whole lot. These are my private helper
methods that I invoke from my more involved algorithm methods. Many
are one or two liners and they generally don't make sense to have
publicly accessible since they're really just internal building blocks
for constructing other more interesting methods.

Cheers
Bent D
--
Bent Dalager - http://www.velocityreviews.com/forums/(E-Mail Removed) - http://www.pvv.org/~bcd
powered by emacs
 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      03-19-2006
Ian Collins schrieb:
> Timo Stamm wrote:
>> It is necessary to have test classes in the same package as the tested
>> class in order to test package private methods.
>>

> Another view that tests that require access to private methods are a
> design smell. Often these can be refactored into objects that can be
> tested in isolation.


Not "private", but "package private".

Package private classes are only visible within the same package (same
directory). They are useful in large APIs where you have a lot of
functionality, but only want to expose a small interface.


Timo
 
Reply With Quote
 
Timo Stamm
Guest
Posts: n/a
 
      03-19-2006
Timo Stamm schrieb:
> | 7. Keep tests close to the class being tested
> |
> | If the class to test is Foo the test class should be called FooTest
> | and kept in the same package (directory) as Foo. The build environment
> | must be configured so that the test classes doesn't make its way into
> | production code.
>
> It is necessary to have test classes in the same package as the tested
> class in order to test package private methods.
>
> But you don't have to put the classes in the same directory. Most IDEs
> support several source folders. You can setup two source folders. For
> example: "src" for your application source, "test" for your test source.
> If you use the same package structure in the test source folder, you can
> test package private methods and it is very easy to deploy only
> application code.



Oops, I didn't realize that the guidelines aren't java-specific and that
this thread is on c.l.java.p as well as c.l.c++.

My objection is specific to java. I doubt that the same applies to c++.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
unit-profiling, similar to unit-testing Ulrich Eckhardt Python 6 11-18-2011 02:00 AM
Unit testing errors (testing the platform module) John Maclean Python 1 04-13-2010 02:11 PM
Test::Unit - Ruby Unit Testing Framework Questions Bill Mosteller Ruby 0 10-22-2009 02:02 PM
unit testing guidelines Jacob C++ 72 03-30-2006 06:32 PM
Re: unit testing guidelines Andrew McDonagh Java 0 03-20-2006 10:33 PM



Advertisments