update explanation for refactoring against failing tests

Author: Xronophobe

chapter_12_organising_test_files.asciidoc

@@ -884,13 +884,15 @@ Don't forget the "Refactor" in "Red, Green, Refactor"::
     ((("Red/Green/Refactor")))
 
 Don't refactor against failing tests::
-    * In general: refactoring against failing tests can easily introduce new
-      issues and make it a lot more difficult to spot them.
-    * Refactoring against failing FTs, however, is often necessary and excusable
-      because FTs address user stories, focusing on the "what" in development.
-      They cover extensive parts of the application, and aren't tightly tied to
-      the code. Unlike unit tests, which focus on the "how" to implement the
-      functionality, guiding the implementation more directly.
+    * The general rule is that you shouldn't mix refactoring and behaviour
+      change. Having green tests is our best guarantee that we aren't changing
+      behaviour. If you start refactoring against failing tests, it becomes much
+      harder to spot when you're accidentally introducing a regression.
+    * This applies strongly to unit tests. With functional tests, because we
+      often develop against red FTs anyway, it's sometimes more tempting to
+      refactor against failing tests. My suggestion is to avoid that temptation
+      and use an early return, so that it's 100% clear if, during a refactory,
+      you accidentally introduce a regression that's picked up in your FTs.
     * You can occasionally put a skip on a test which is testing something you
       haven't written yet.
     * More commonly, make a note of the refactor you want to do, finish what