edits and tweaks in 27 hot lava

Author: hjwp

chapter_27_hot_lava.asciidoc

@@ -85,14 +85,14 @@ and at the higher level of "does it all hang together?".
 Our tests need to be fast enough to write,
 but more importantly, fast to run.
 We want to get into a smooth, productive workflow,
-and try to enter into that holy credo of programmers, the "flow state".
+and that holy credo of programmers, the "flow state".
 Beyond that, we want our tests to take some of the stress out of programming,
 encouraging us to work in small increments,
 with frequent bursts of dopamine from seeing green tests.
 
 ==== Driving Better Design
 
-Finally our tests should help us to write better code.
+And our tests should help us to write _better_ code.
 Firstly, by enabling fearless refactoring.
 Secondly, by giving us feedback on the design of our code.
 Writing the tests first lets us think about our API from the outside-in,
@@ -103,9 +103,7 @@ As we'll see, designing code to be more testable
 often leads to code that has clearly identified dependencies,
 and is more modular and more decoupled.
 
-
-
-As we continuously think about what kinds of tests to write
+As we continuously think about what kinds of tests to write,
 we are trying to achieve the optimum balance of these different desiderata.
 
 
@@ -143,10 +141,10 @@ But people will often tell you that a "true" unit test should be more isolated.
 It's meant to test a single "unit" of software,
 and your database "should" be outside of that.
 Why do they say that?
-Apart from the lovely warm glow of smug that they get from should-ing us?
+Apart from the smug from should-ing us?
 
 As you can tell,
-I think the argument from definitions is a bit of a red herring.
+I think the argument from _definitions_ is a bit of a red herring.
 But you might hear instead, "the database is hot lava!"
 as Casey Kinsey put it in a memorable DjangoCon talk.
 There is real feeling and real experience behind these comments.
@@ -164,17 +162,19 @@ At PythonAnywhere, our functional test suite didn't just rely on the database,
 it would spin up a full test cluster of 6 virtual machines.
 A full run used to take at least 12 hours,
 and we'd have to wait overnight for our results.
+That was one of the least productive parts of an otherwise extraordinary workflow.
 
 At Kraken, the full test suite does only take about 45 minutes,
+which is not bad for nearly 10 million lines of code,
 but that's only thanks to a quite frankly ridiculous level of parallelisation
 and associated expenditure on CI.
 We're now spending a lot of effort on trying to move more of our unit
 tests to being "true" unit tests.
 
 The problem is that these things don't scale linearly.
 The more database tables you have,
-the more foreign keys between them,
-and the relationships can start to increase geometrically.
+the more relationships between them,
+and that starts to increase geometrically.
 
 So you can see why, over time, these kinds of tests
 are going to fail to meet our desiderata because they're too slow
@@ -334,7 +334,6 @@ by Dave Farley.
 Well that's all very well Harry, you might say,
 but our current test setup is nothing like this!
 How do we get there from _here_?
-
 We've seen how to use mocks to isolate ourselves from external dependencies.
 Are they the solution then?
 
@@ -363,15 +362,14 @@ NOTE: I'm glossing over the use of mocks in a "London-school"
 === The Actual Solutions Are Architectural
 
 The actual solution to the problem isn't obvious from where we're standing,
-but it actually lies in rethinking the architecture of our application.
+but it lies in rethinking the architecture of our application.
 In brief, if we can _decouple_ the core business logic of our application
 from its dependencies, then we can write true unit tests for it,
 that do not depend on those, um, dependencies.
 
 Integration tests are most necessary at the _boundaries_ of a system--at
 the points where our code integrates with external systems,
 like the database, filesystem, network, or a UI.
-
 Similarly, it's at the boundaries that the downsides of test isolation and
 mocks are at their worst, because it's at the boundaries that you're most
 likely to be annoyed if your tests are tightly coupled to an implementation,
@@ -460,7 +458,7 @@ Martin Fowler and Kent Beck,
 which you can follow https://martinfowler.com/articles/is-tdd-dead/[here].
 
 Like any technique, these patterns can be misused,
-but I wanted to make the case for the upside of these patterns:
+but I wanted to make the case for their upside:
 by making our software more testable,
 we also make it more modular and maintainable.
 We are forced to clearly separate our concerns,
@@ -501,7 +499,6 @@ image::images/frog-in-a-pan-placeholder.png["An illustration of a frog being slo
 
 For small to medium-sized applications, as we've seen, the Django test runner
 and the integration tests it encourages us to write are just fine.
-
 The problem is knowing when it's time to make the change
 to a more decoupled architecture, and start striving explicitly for the Test Pyramid.
 
@@ -510,29 +507,26 @@ since I've only experienced environments where either someone else made the deci
 before I joined, or the company is already struggling with a point where it's
 (at least arguably) too late.
 
-Another is, the longer you leave it, the harder it is.
-
-Yet another is, because the pain is only going to set in gradually,
+One thing to bear in mind, though, is that the longer you leave it, the harder it is.
+Another is that because the pain is only going to set in gradually,
 like the apocryphal boiled frogs, you're unlikely to notice
 until you're past the "perfect" moment to switch.
-
-One more suspicion:  it's never going to be a convenient _time_ to switch.
+And on top of that, it's _never_ going to be a convenient time to switch.
 This is one of those things, like tech debt,
 that are always going to struggle to justify themselves in the face of more
 immediate priorities.
 
 So perhaps one strategy would be an Odysseus pact,
 tie yourself to the mast, and make a commitment--while the tests are still fast--to
 set a "red line" for when to switch.
-"if the tests ever take more than 10 seconds to run locally,
+For example: "if the tests ever take more than 10 seconds to run locally,
 then it's time to rethink the architecture".
 
 
 I'm not saying 10 seconds is the right number by the way.
 I know plenty of people who are perfectly happy to wait 30 seconds.
 And I know Gary Bernhardt, for one, would get very nervous
 at a test suite that takes more than 100ms.
-
 But I think the idea of drawing that line in the sand, wherever it is,
 _before_ you get there, might be a good way to fight the "boiled frog" problem.
 
@@ -551,16 +545,18 @@ and spot the problems before they get too large.
 In this book, I've been able to show you how to use TDD,
 and talk a bit about why we do it, and what makes a good test,
 but we're inevitably limited by the scope of the project.
-
 What that's meant is that some of the more advanced uses of TDD,
 particularly the interplay between testing and architecture,
 have been beyond the scope of this book.
-But I hope that this chapter has given you enough of a guide to find your way
+
+But I hope that this chapter has been a bit a guide to find your way
 around that topic as your career progresses.
 
 
 ==== Further Reading
 
+A few places to go for more inspiration:
+
 Fast Test, Slow Test and Boundaries::
     Gary Bernhardt's talks from Pycon
     https://www.youtube.com/watch?v=RAxiiRPHS9k[2012] and
@@ -613,3 +609,6 @@ A Take From the World of Functional Programming::
     explores the idea of "Functional Core, Imperative Shell".
     Don't worry, you don't need a crazy FP language like Haskell or Clojure to understand it,
     it's written in perfectly sensible JavaScript.
+
+
+Happy testing!