A list for the developers of CellML tools

Text archives Help


RE: [[cellml-dev] ] "Tests first" style


Chronological Thread 
  • From: Richard Christie <r.christie AT auckland.ac.nz>
  • To: cellml-tools-developers Mailing List <cellml-tools-developers AT lists.cellml.org>
  • Subject: RE: [[cellml-dev] ] "Tests first" style
  • Date: Wed, 1 Apr 2015 02:35:58 +0000
  • Accept-language: en-GB, en-NZ, en-US

For Zinc I typically write the test while writing the implementation,
sometimes progressing a fair bit before starting the implementation. However,
I always commit the test first, and when it has shown the failure on BuildBot
then commit the implementation (typically only minutes after the test commit).

I would be happier about committing tests earlier if we didn't have dozens of
tests per test binary (one binary per test is not feasible). A single test
marks the whole test binary as failed which is problematic if others are
concurrently developing. (OTOH If someone could show me where the console
output from each test is on BuildBot, I'd be most grateful!)

We don't use the test code to communicate proposed API usage. When we are
being good we propose APIs on the tracker item well before this. However, in
practice I do use the test code to check how it looks from the client's
perspective (i.e. me!) and it often leads to renames or other changes.

For bugs in production code it's definitely a good idea to get a failing test
put in at the earliest time, but again it's more practical if the granularity
of test failure reporting can show you only it is failing.

Regards,
Richard


From:
cellml-tools-developers-request AT lists.cellml.org

[mailto:cellml-tools-developers-request AT lists.cellml.org]
On Behalf Of Randall Britten
Sent: Wednesday, 1 April 2015 3:16 p.m.
To: cellml-tools-developers Mailing List
Subject: [[cellml-dev] ] "Tests first" style

Hi

We had a discussion this morning about whether tests should be committed even
if they would not compile.

My approach has been to code the test and then the implementation, get the
tests passing, cripple the implementation, check that the tests fail, and
make a commit. Then I "uncripple" the implementation, and make the next
commit. This achieves the goal of "test first style", since it validates
that the implementation is the reason the tests pass.

Others have recommended committing just the test code, which won't compile,
and then coding the implementation and committing the implementation, so no
the tests compile and pass. However, this does not validate that the
implementation is what caused the tests to pass, since there is no commit
which shows the tests failing followed by a diff that shows what it is that
causes the tests to pass.

Keen to hear from the community on this.

Regards,
Randall




Archive powered by MHonArc 2.6.18.

Top of page