Kent Beck: Composable Tests

Join the discussion

• Hacker News
• > If a test runs by first setting up its own test fixture, creating from scratch all the data it will be using as input, then that test is guaranteed to be isolated. It doesn’t matter what order you run the tests, the results will be exactly the same.

  Completely backward. This definition requires isolation, rather than granting it.

  In reality, you (or your test framework) provides the isolation by hobbling along, executing only one test at a time.

  by mrkeen
• Why wouldn't you use parameterized tests or compose your setup out of fixtures that run the shared setup code?

  Running a test, then running it a second time, then asserting something else.. is just weird.

  by cadamsdotcom
• What I do not like about that kind of example is its abstractiveness. Yes sure you can argue about testing `doSomething()` and it all falls apart when there is an actual business scenario to test.
  by npodbielski
• I'm done listening to smart people proposing fixes for my dumb code.

  Either I'm not smart or disciplined enough to make it work, or my colleagues are not. Mostly both.

  by grim_io
• Ah Kent Beck, I see your style of writing trivial examples hasn't changed
  by nhgiang
• Someone had written a comment about whether Kent Beck has heard of global and static variables. That comment seems to have been deleted.

  Kent Beck is co-creator [1] of the JUnit Testing Framework and has most definitely heard of static and global variables.

  [1] https://junit.org/junit4/project-info.html

  by solarengineer
• > Deleting test1 loses us another property from the Test Desiderata—tests should be specific. That’s the property of tests where, when one fails, you know exactly where the problem is.

  Contra Kent and, it seems, prevailing wisdom, I think simply deleting test1 is by far the simplest, clearest and best way. Provided that your testing framework tells you which specific assertion failed (e.g., by telling you the line number in a stack trace), you do know exactly where the problem is. The only thing you lose is that a test function or method may now cover several related checks (they are related by "setup dependence"), meaning their names may need to be somewhat broader. But you can still describe the specific semantics of each assert() check in a one-line comment beforehand if you want. There's no need to cram it into a legal method name.

  ETA: Prefer to write tests whose "arrange" steps are as simple as possible, to minimise unnecessary overlaps. But if the simplest possible "arrange" step for a test is something that itself needs to be checked for correctness, just do that check right there, and nowhere else. Anything beyond that is ceremony that adds nothing useful.

  by akoboldfrying
• I had a test suite with thousands of tests. One way of running it was to take all the passing tests, and then run them repeatedly in random order.

  This found new bugs involving unintended persistent state.

  by pfdietz