Cc: address@hidden
From: Przemysław Wojnowski<address@hidden>
Date: Thu, 12 Nov 2015 22:42:43 +0100
W dniu 12.11.2015 o 21:55, Eli Zaretskii pisze:
In TDD, they teach you to write a test for a spec that isn't
implemented yet. The test fails, of course (which is a Good Thing:
now you know that your test indeed will catch a non-compliant
implementation), and then you implement the spec to see that it now
succeeds. If you work that way, tests _do_ drive the development.
What do you mean by "spec" here?
Sorry for using jargon here. By "spec" I meant the specification of
the module, i.e. the APIs of its methods, and the set of requirements
that define what should be the result(s) of invoking the various
methods with the various possible combinations of arguments and given
the relevant environmental conditions.
A simple example of a "spec" for a single function is what you see
here:
http://pubs.opengroup.org/onlinepubs/009695399/functions/stat.html
I've never seen nor used TDD (and I use it very often) with "spec".
What I've seen, though, was using TDD to implement User Stories (Use
Cases), which are descriptions of functionality, but far from formal
specifications - if this is what you mean.
A spec in the terminology I used is the set of formal requirements
produced by analyzing those use cases.
For the purposes of this discussion, I think it's immaterial whether
the "spec" is formal or not. What's important is that you can
unequivocally determine what the code should do, and write the tests
which check that.
Anyway, TDD drives design (you implement only as much as is needed to
make the tests pass) and, by side effect, gives strong regression test
suite, which _enables_ refactoring.
Indeed.