Differences

This shows you the differences between two versions of the page.

--- technology:opinions:abiasedguidetounittests [2021/09/05 19:47] – Owen Mellema
+++ technology:opinions:abiasedguidetounittests [2021/09/06 22:52] (current) – Owen Mellema
@@ Line 1: / Line 1: @@
 ====== A Biased Guide to Unit Tests ======
+//This article was written to explain my thoughts on how Unit Testing should be done. Your mileage may vary.//
 ===== Introduction =====
 Testing is important. It's really fucking important. Yes, it can be annoying, but so is checking that you have your parachute on before jumping out of a plane. Despite this, the world of thought surrounding unit testing still seems to be in its infancy compared to thought about general programming. Many very competent developers will rush through the process of unit testing, making significant errors in the process, and many other competent developers will look at the unit tests and not see anything wrong with them.
@@ Line 81: / Line 82: @@
 ===== Value Hierarchies =====
-When we write functional code, there is a hierarchy of value that defines good code.
+When we write functional code, there is a hierarchy of value that defines quality.
   - Correct: It should do what we expect.
   - Efficient: It should not waste time or space.
@@ Line 91: / Line 92: @@
   - Honest: The code should test the SUT.
   - Comprehensive: The code should test all edge cases.
-  - Brittle: Small changes in the SUT's code should break the tests. (Deterministically)
   - Explicit: The code should "explain" the actual functionality of the SUT.
 This difference in value means that applying best practices from one paradigm to the other causes poor outcomes. For example, when writing functional code, it is considered an antipattern to copy and paste code. Instead, a good program has similar tasks being handled in the same way. Developers will sometimes fall into the trap of thinking that this is for their benefit, because it is more convenient. While this is true, the more important reason that copying and pasting is considered an antipattern is because it is likely to introduce bugs, therefore causing problems with our most important functional requirement: Correctness. When a change needs to be made, that change should be made in exactly one location, not many different locations. Inevitably, one of those locations will be missed.
-However, I would argue that, for testing, copying and pasting is not an antipattern. This is because we want our tests to be brittle. If abstracting repeated code causes our tests to become more resilient, abstraction itself can become an antipattern.
+However, I would argue that, for testing, copying and pasting is not an antipattern. This is because correctness is not a concern when writing tests. While reducing repeated code can be good for comprehension in some circumstances, it can also damage comprehension. Worse still, if done incorrectly, it can also damage the honesty of our tests.
+===== Writing Honest Tests =====
-===== Writing Honest and Brittle Tests =====
 ==== The Topology of Testing ====
 Tests are, ideally, all about data. We have some SUT, an input, and a desired output (or outcome). We feed the input into the SUT and check if the result matches the desired output. Below, I have mapped out what this looks like in a pseudo-flow chart.
@@ Line 324: / Line 323: @@
 //Feed packaged input into SUT
-FibonacciResponse packagedOutput = Fibonacci.fib3(fibonacciCriteria);
+FibonacciResponse packagedOutput = Fibonacci.fib(fibonacciCriteria);
 //Create a packaged expected output.
@@ Line 357: / Line 356: @@
 So, save yourself the headache, and don't skip the extractor. The rule here is: **One side of the assertion should be connected directly to the expected output**.
+==== Summary ====
+The rules we have discussed in this section are:
+  - One side of the assertion should be connected to the SUT.
+  - The other side of the assertion should be connected directly to the output.
+  - The only logic in the test should be in the SUT.
+===== Writing Comprehensive Tests =====
+I'm not going to write about this, as our understanding of testing edge cases is pretty good.
+===== Writing Explicit Tests =====
+When we write tests, we are writing the most complete and accurate documentation of the functionality of our SUT. If I write a javadoc comment explaining what the SUT does, the reader must take my word for it that this is what it does. For all the reader knows, I might be lying (or just incorrect). However, when we write tests, our documentation is self-proving. The reader can run the tests and be assured that this is how the SUT will act.
+Despite this, since we write tests using code and code is not necessarily easy to read, we must make a special effort to ensure that our testing code is readable. Luckily, if you are following my advice from above, the logical complexity of the testing code should be low.
+==== Using Given-When-Then Correctly ====
+The Given-When-Then paradigm is, in most cases, the best way to organize tests. My only ask is that when you write GWT tests, you do it //the right way//. Otherwise, you'll just be cluttering up your codebase with unnecessary nesting.
+The biggest strength of GWT is that every part of the testing topology is represented by a concept in GWT:
+  * **Given** corresponds to defining and packaging input.
+  * **When** corresponds to calling the SUT and extracting.
+  * **Then** corresponds to extracting((This can also be done in the When step, if it is more convenient)) and asserting an output.
+{{ :technology:opinions:in-gwt.jpg?400 |}}
+A good strategy for accomplishing this is to define your input and output variables in your root class, and then use a @BeforeEach to set a variable to what you want it to be for the test. Here's what that would look like for testing the 0 case for Fibonacci.
+<code:java>
+@Nested
+class FibonacciTestGWT {
+    FibonacciCriteria criteria;
+    FibonacciResponse response;
+    @Nested
+    class GivenAnIOf0 {
+        @BeforeEach
+        void init() {
+            criteria = mock(FibonacciCriteria.class);
+            when(criteria.getNumber()).thenReturn(0);
+        }
+        @Nested
+        class WhenCallingFibonacci {
+            @BeforeEach
+            void init() {
+                response = Fibonacci.fib(criteria);
+            }
+            @Test
+            void thenResultIs0() {
+                int result = response.getResult();
+                assertEquals(0, result);
+            }
+        }
+    }
+}
+</code>
+==== Effective abstraction ====
+Here's a few ideas for cleaning up your tests with abstraction. Remember, in all of this, the name of the game is //readable//, not //convenient//! All decisions regarding cleaning must be made with an eye for the reader.
+  * Do as little packaging in your setup methods as possible. Instead, move the heavy lifting of packaging to dedicated private methods, like this:
+<code:java>
+void init() {
+    criteria = createMockCriteria(0);
+}
+private FibonacciCriteria createMockCriteria(int number)
+{
+    FibonacciCriteria criteria = mock(FibonacciCriteria.class);
+    when(criteria.getNumber()).thenReturn(number);
+    return criteria;
+}
+</code>
+  * If you need more than one parameter in your setup method, consider using a DTO with a builder to increase comprehension.
+<code:java>
+void init() {
+    criteria = createMockCriteria(FibonacciCriteriaMockDTO
+        .builder()
+        .number(0)
+        .build());
+}
+private FibonacciCriteria createMockCriteria(FibonacciCriteriaMockDTO fibonacciCriteriaMockDTO)
+{
+    FibonacciCriteria criteria = mock(FibonacciCriteria.class);
+    when(criteria.getNumber()).thenReturn(fibonacciCriteriaMockDTO.number);
+    return criteria;
+}
+@Builder
+class FibonacciCriteriaMockDTO {
+    int number;
+}
+</code>
+  * Don't abstract away the actual calling of the SUT. After all, that's the most important part.
+  * Writing helper assertion methods can be helpful, but they can also confuse readers if not done right. Follow these tips to write a good helper assert.
+    * Your assertion should take two arguments at most (excluding housekeeping arguments like "delta" for comparing floats)
+    * The first argument should be the packaged output, and the second argument should be the primitive to test.
+    * The name of the helper should begin with "assert", followed by the concept being tested. Don't use the word "correct", it's redundant.
+    * All asserts in the helper assertion method should be conceptually related. If possible, use just one.
+<code:java>
+@Test
+void thenResultIs0() {
+    assertResult(response, 0);
+}
+private void assertResult(FibonacciResponse response, int expectedResult)
+{
+    int result = response.getResult();
+    assertEquals(expectedResult, result);
+}
+</code>