style: pre-commit fixes

Author: pre-commit-ci[bot]

docs/pages/principles/testing.md

@@ -486,61 +486,67 @@ def test_pytest(mocker):
 
 The range of inputs that test cases validate is an important decision.
 
-When the need for extensive testing starts to conflict with the readability of test cases
-and their usefulness as documentation for users and other developers, the tests should
-be re-organized into public-facing (concise, expressive, easily readable),
-and technical (complex, extensive) test files.
+When the need for extensive testing starts to conflict with the readability of
+test cases and their usefulness as documentation for users and other developers,
+the tests should be re-organized into public-facing (concise, expressive, easily
+readable), and technical (complex, extensive) test files.
 
 - To maintain readability:
-  - tests may need to include fewer inputs 
+  - tests may need to include fewer inputs
   - extensive edgecase testing may be moved into different sections or files
   - the code itself may need to be refactored
-- Avoid testing invalid input; the range of invalid input is infinite, and
-    is the programming equivalent of trying to prove a negative.
-- Focus on inputs relevant to the code under test, and avoid testing the code in dependencies. 
-  Some integration testing of specific behaviors your code relies on is justifiable.
-- [Fuzz Tests](#fuzz-tests) are the best place to handle extensive and exhaustive input testing.
-
+- Avoid testing invalid input; the range of invalid input is infinite, and is
+  the programming equivalent of trying to prove a negative.
+- Focus on inputs relevant to the code under test, and avoid testing the code in
+  dependencies. Some integration testing of specific behaviors your code relies
+  on is justifiable.
+- [Fuzz Tests](#fuzz-tests) are the best place to handle extensive and
+  exhaustive input testing.
 
 ### In Public Interface Tests
 
-These are the most appropriate place to test certain invalid inputs and dependencies. 
-Public Interface tests act like a contract with users; each behavior that is tested is like a promise that
-users can rely on, and expect that it will not change without warning (and probably a major version bump).
-So any input/output and side-effects included in these tests should be considered *officially supported behavior*
-and given careful consideration.
+These are the most appropriate place to test certain invalid inputs and
+dependencies. Public Interface tests act like a contract with users; each
+behavior that is tested is like a promise that users can rely on, and expect
+that it will not change without warning (and probably a major version bump). So
+any input/output and side-effects included in these tests should be considered
+_officially supported behavior_ and given careful consideration.
 
 ### In project level integration tests
 
-These are a good place to handle more extensive input testing. Integration tests already tend to be more verbose,
-with a lot of setup and teardown, and much more behavior to cover than other kinds of tests.
-These are the kinds of tests that should focus on edgecases.
-
+These are a good place to handle more extensive input testing. Integration tests
+already tend to be more verbose, with a lot of setup and teardown, and much more
+behavior to cover than other kinds of tests. These are the kinds of tests that
+should focus on edgecases.
 
 ### In Unit Tests
 
-Unit Tests should focus on the "happy-path" of execution. In most cases one representative
-example of the *expected* input is sufficient. The test case should illustrate how the unit
-is expected to be used.
+Unit Tests should focus on the "happy-path" of execution. In most cases one
+representative example of the _expected_ input is sufficient. The test case
+should illustrate how the unit is expected to be used.
 
-Invalid input should only be tested when the unit itself includes logic to handle that invalid input.
+Invalid input should only be tested when the unit itself includes logic to
+handle that invalid input.
 
 for example, this code:
+
 ```python
 def foo(x: int):
     return x + 1
 ```
-should not test its behavior when passed a string (the type annotation already covers that).
+
+should not test its behavior when passed a string (the type annotation already
+covers that).
 
 This code should be tested with a string, to cover the exception path.
+
 ```python
 def bar(x):
     if type(x) is str:
-        raise RuntimeError('invalid input')
+        raise RuntimeError("invalid input")
     return x + 1
 ```
 
-
 ## Additional Types of Test Suites
 
 A non-exhaustive discussion of some common types of tests.