[u-u] On testing Re: jobs @ rakuten/kobo

[Eric Siegerman]

On Sun, Aug 06, 2017 at 10:35:35AM -0400, D'Arcy Cain wrote:
> Tests are not supposed to be written by someone else.

*Unit* tests are not supposed to be written by someone else.

I have no personal experience with this, but I believe there is a
case to be made for having someone else write the integration/QA
tests -- especially if you're working from a detailed
specification (a written-first man page, perhaps...)  Verifying
that two independent brains interpreted the spec the same way is
a useful test of the spec document itself.


> The order is;
>  1. Write the test for a new feature or function
>  2. Run the test to prove that it fails
>  3. Write code until the test passes
>  4. Stop programming

The version I've read, and used, is:
  1 & 2.  As above

  3. Write code until the test passes.  Write it any old way,
     taking whatever shortcuts get you to "green".

  4. Clean up your mess, *without* changing the functionality,
     and *without* changing the tests.

If the tests from (3) still pass after (4), that tells you that
you succeeded in holding the functionality constant (within the
limits of the tests' completeness, that is).

For example, suppose you have atof(), and want to implement
strtod(): At step (3), do the ugly clone-and-modify thing, adding
tests as you go.  Then, at step (4), eliminate the duplication
(in this case, probably by reimplementing atof() as a call to
your new strtod()).

  - Eric