Composable Tests
newsletter.kentbeck.com
Composable Tests
1–10 of 67 posts
Re: Composable Tests
#2I'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.
Re: Composable Tests
#3I'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.
What he wrote is basically "don't repeat in test X what you already tested in test X-1".
It's not as much composition as compounding, and can work quite well.
Let's say something takes 20 steps, and you want to test all 20.
Instead of this:
test 1:
do step 1, assert step 1
test 2:
do step 1, assert step 1
do step 2, assert step 2
test 3:
do step 1, assert step 1
do step 2, assert step 2
do step 3, assert step 3
...
test 1:
do step 1, assert step 1
test 2:
do step 1
do step 2, assert step 2
test 3:
do step 1
do step 2
do step 3, assert step 3
...
As most things, it depends on what those steps are. Perhaps you only need that one final (integration) test instead of 20 intermediate unit ones.
Re: Composable Tests
#4I'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.
Kent Beck is smart because he proposes fixes that work in real life, as in environments with dumb code and undisciplined people.
I can very much recommend his latest book ”Tidy first?”. It’s extremely short and concise, and is perfect for a very light book club within any tech team.
Re: Composable Tests
#5I 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.
Re: Composable Tests
#6I'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.
Kent Beck is smart because he proposes fixes that work in real life, as in environments with dumb code and undisciplined people. I can very much recommend his latest book ”Tidy first?”. It’s extremely short and concise, and is perfect for a very light book club within any tech team.
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.
Re: Composable Tests
#7> 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.
Re: Composable Tests
#8I'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.
What he wrote is basically "don't repeat in test X what you already tested in test X-1". It's not as much composition as compounding, and can work quite well. Let's say something takes 20 steps, and you want to test all 20. Instead of this: test 1: do step 1, assert step 1 test 2: do step 1, assert step 1 do step 2, assert step 2 test 3: do step 1, assert step 1 do step 2, assert step 2 do step 3, assert step 3 ... y…
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
But it could also do things like skip test 3 if tests 2 or 1 failed - because it knows about the relationship.
Re: Composable Tests
#9[flagged]
Re: Composable Tests
#10I'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.
What he wrote is basically "don't repeat in test X what you already tested in test X-1". It's not as much composition as compounding, and can work quite well. Let's say something takes 20 steps, and you want to test all 20. Instead of this: test 1: do step 1, assert step 1 test 2: do step 1, assert step 1 do step 2, assert step 2 test 3: do step 1, assert step 1 do step 2, assert step 2 do step 3, assert step 3 ... y…
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 and it's repetitive to read.