Re: Dos and don'ts in C++ unit testing?
On Feb 22, 2:49 am, "kevin cline" <kevin.cl...@gmail.com> wrote:
On Feb 20, 6:52 am, "James Kanze" <james.ka...@gmail.com> wrote:
kevin cline wrote:
On Feb 16, 7:59 am, Francis Glassborow <fran...@robinton.demon.co.uk>
wrote:
In article <1171546178.649654.103...@a34g2000cwb.googlegroups.com>,
James Kanze <james.ka...@gmail.com> writes
What the OP said, "code a little, test a lot" made me
think it meant you couldn't write 100 lines without
spending a long time testing them.
There is another way f viewing that injunction.
Write a little code
test it
add a little more code
test it
add a little more code
test it
etc.
I prefer to:
write a little test
code until all tests pass
write another test
code until all tests pass
...
The art is in figuring out what to test next.
Don't the requirement specifications tell you that?
Usually not. For example, if one were attempting to write an HTML
browser, it wouldn't be wise to start with a test to display an
complex web page. Instead, I would first test the display of an empty
page. Then I might test the display of simple text elements.
If I were attempting to write an HTML browser, I'd start with a
detailed description of what it should and should not support.
I'd then do some design, to break it up into smaller pieces; I
wouldn't just sit down and write it as a single component. And
of course, each of the smaller pieces would have a requirements
specification concerning what that piece should do, and would be
designed, and---given the complexity of a browser---probably
broken up into still smaller pieces. In the end, I would end up
with pieces which were small enough to work with.
Of course, in practice, one person probably wouldn't write a
browser alone. It would be a team effort. And the tests for
the complete browser would probably be developed by the
integration team, in parallel with development. So the test
suite would be complete and ready as soon as you started getting
complete builds.
The real art is figuring out how to write a test which will fail
if the code doesn't meet the requirement specifications...
(I, and a lot of other people,
I'm sure, would be very interested if you know how to write a
test case for libstdc++ bug no. 21334, for example.)
My approach for multi-threaded code is to attempt to write code which
is provably thread-safe.
Exactly what I do. And the justification of the proof is in
code review; unless the reviewers are convinced that my proof is
valid, the code doesn't pass review.
I've yet to find an effect means of testing thread-safety (but
I'd like to).
Usually this means writing a rather small class, defining the valid
states for the class, and then proving that instances are always in a
valid state except when locked.
Which still doesn't address things like race conditions.
(Sometimes, too, it's non-trivial to define "valid state". One
could argue that in the bug cited above, the instance of
basic_string is always in a valid state. Just not the correct
valid state with regards to other things that are being done.
Of course, if the state is not the correct one, it's not really
valid, but my point is that whether a state is valid or not may
depend on context.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]