Composable Tests

Maybe I misread. When I see a setUp() in a test suite, 9 times out of 10 it's to handle something shared and bulky, like a database. Otherwise you'd just do the thing - assert(expected, myService.run(input)); If I saw an extra myService.reset() or myService.setUp() I would suspect it's either in anticipation of a bad state (from a previous test) or to be a good neighbour for the next test which will run.

In the cases where each unit test does have it's own individual Postgres or whatever, sure.

I assure you, there is no such thing as a book club at my job, especially not one focused on technical writing :)

I agree, both with your analysis of him and your review of "Tidy first?". We read and discussed it at work, and I enjoyed it a lot.

I wonder if it would work do design something that was able to say

    test 1: 
       do step 1, assert step 1

    test 2:
       requires: test 1
       do step 2, assert step 2

    test 3:
       requires: test 2
       do step 3, assert step 3

    test 4:
       requires: test 2
       do step 3, assert step 3

If the assertion of each test doesn't change any state, that might make things easier to read. Though, given that I haven't spent much time pondering it, I expect it could have it's own problems.

But it could also do things like skip test 3 if tests 2 or 1 failed - because it knows about the relationship.

IMO it seems kind of terrible.

You're not going to remember what tests "test 3" relies on. They aren't actually linear progressions 123. They will be "test this", "test that". If 3 fails you're going to want to immediately go and add all those asserts back to help you debug your assumptions.

The tests _will_ drift and that should be fine. Implicitly depending on other tests doesn't really get me anything.

What's the problem of only keeping test 3 if it depends on test 2 and 1 passing anyway?

The article mentions not to do this because "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." but you'll know what line it failed on. And some test runners let you break a test into steps, where groups of lines are given a description.

Or put each step + assert in a helper function (e.g. `doStep1AndAssert()`), and each test only calls these helper functions?

Nothing is perfect, but copy/pasting chunks between tests like this isn't great when you want to refactor it's repetitive to read.

I think I disagree with Kent, but your explanation is clearer, so I'll object here.

There's nothing wrong with hitting the same assertion multiple times, even if it doesn't sit nicely in your gut.

From a purely philosophical point of view: If I have testFoo(), testBar(), and testFooAndBar(), and my Foo is plain wrong, then both testFoo() and testFooAndBar() must fail. Anything less is misleading/dishonest.

From a practical side: Changes happen. Someone will remove testBar(), and then you're down to 0 assertions on Bar, even though you have a test claiming to testFooAndBar(). It's not even a crazy hypothetical. Someone with a different test philosophy will think (to quote TFA) "They are redundant! Something must be wrong." and delete testBar() because obviously testFooAndBar() already covers it.

Anyway, we all know how to deal with repetition. That's what programming is!

  testFoo()
  _ = validateFoo(foo())

  testBar()
  _ = validateBar(bar())

  testFooAndBar()
  foo = validateFoo(foo())
  bar = validateBar(bar())
  _   = validateFooAndBar(fooAndBar(foo, bar))

If you need test1's logic as setup for test2, then you already have that "linear timeline" -- for test2 all by itself. Additionally (that is, redundantly) running the same setup code "prefix" by itself in test1 doesn't remove test2's linear timeline.

ETA: I'm assuming your objection to a "linear timeline" is that it reduces the potential for running tests in parallel -- have I got that right? If not, what do you see as being the problem with it?