Re: Coding Standards
On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 3:41 am, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
[...]
More importantly, assertions and unit tests aren't part of the
documentation.
They have majorly overlapping and complementary roles.
They have distinctly different roles. In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do, and you don't really
"know" anything until you've written it down.
But they (well written, test first unit tests) do bridge the gap between
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tests.
They are an implementation of part of the specification. But
you can't write them until you have the specification: a precise
English (or other human) language document as to what the code
is to do. And there are more than a few cases that they simply
cannot cover, and for the most part, they are both more verbose
than a requirement specification should be, and fail to say a
lot of things that are essential in a requirement specification.
For some very
simple functions, just the function name may be sufficient, but
99 times out of a 100, you'll need more. Some of that more can
be expressed within the language---if the return type is int,
for example, there is an explicit post-condition that the return
value won't be 1.5. But there are still a lot of things that
cannot easily be expressed, even taking assertions into account.
And as it currently stands, C++ has no mechanism for specifying
the assertions in a way that the user can see them.
That is where unit and more importantly customer acceptance test
frameworks come in. They provide the required vocabulary to enable
developers and customers/test engineers to to specifying the assertions
in a meaningful way.
If the customer can read and write unit tests, he's perfectly
capable of implementing the code himself, and doesn't need you.
My customers are bankers, or telephone specialists, or simply
application programmers, who are completely incapable of writing
or reading the level of C++ I program at (framework and system
level code). Asking a customer to guess the thread safety
guarantees made by the class, for example, just by reading the
unit tests, is simply ridiculous.
and if
you can't beat unit tests, join them!
Except that unit tests are a lot more wordy than good
documentation, and if you don't have the documentation to begin
with, then you have no way of verifying that the unit tests are
complete.
That is because thy provide more detail than the documentation.
Actually, they provide less useful information---they are more
verbose, because the compiler requires a lot more unnecessary
and uninteresting detail than the user does. But they don't
make a succinct abstraction or summary of anything, which is the
most important thing for the user. How do you determine the
role of a class in an application from its unit tests?
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34