Differences

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

--- technology:opinions:abiasedguidetounittests [2021/09/06 22:18] – [Paradigms] 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 322: / Line 323: @@
 //Feed packaged input into SUT
-FibonacciResponse packagedOutput = Fibonacci.fib3(fibonacciCriteria);
+FibonacciResponse packagedOutput = Fibonacci.fib(fibonacciCriteria);
 //Create a packaged expected output.
@@ Line 412: / Line 413: @@
 </code>
 ==== Effective abstraction ====
-Here's a few ideas for cleaning up your tests with 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>
-@Nested
+void init() {
-class FibonacciTestGWT {
+    criteria = createMockCriteria(0);
-    FibonacciCriteria criteria;
+}
-    FibonacciResponse response;
-    @Nested
+private FibonacciCriteria createMockCriteria(int number)
-    class GivenAnIOf0 {
+{
-        @BeforeEach
+    FibonacciCriteria criteria = mock(FibonacciCriteria.class);
-        void init() {
+    when(criteria.getNumber()).thenReturn(number);
-            createMockCriteria(0);
+    return criteria;
-        }
-        @Nested
-        class WhenCallingFibonacci {
-            @BeforeEach
-            void init() {
-                response = Fibonacci.fib3(criteria);
-            }
-            @Test
-            void thenResultIs0() {
-                int result = response.getResult();
-                assertEquals(0, result);
-            }
-        }
-    }
-    private FibonacciCriteria createMockCriteria(int number)
-    {
-        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. (I can't take credit for this idea, it actually comes from a person I work with, although here I have done it differently than they have)
+  * If you need more than one parameter in your setup method, consider using a DTO with a builder to increase comprehension.
 <code:java>
-@Nested
+void init() {
-class FibonacciTestGWT {
+    criteria = createMockCriteria(FibonacciCriteriaMockDTO
-    FibonacciCriteria criteria;
+        .builder()
-    FibonacciResponse response;
+        .number(0)
+        .build());
+}
+private FibonacciCriteria createMockCriteria(FibonacciCriteriaMockDTO fibonacciCriteriaMockDTO)
+{
+    FibonacciCriteria criteria = mock(FibonacciCriteria.class);
+    when(criteria.getNumber()).thenReturn(fibonacciCriteriaMockDTO.number);
+    return criteria;
+}
-    @Nested
-    class GivenAnIOf0 {
-        @BeforeEach
-        void init() {
-            createMockCriteria(FibonacciCriteriaMockDTO
-                    .builder()
-                    .number(0)
-                    .build());
-        }
-        @Nested
-        class WhenCallingFibonacci {
-            @BeforeEach
-            void init() {
-                response = Fibonacci.fib3(criteria);
-            }
-            @Test
-            void thenResultIs0() {
-                int result = response.getResult();
-                assertEquals(0, result);
-            }
-        }
-    }
-    private FibonacciCriteria createMockCriteria(FibonacciCriteriaMockDTO fibonacciCriteriaMockDTO)
-    {
-        criteria = mock(FibonacciCriteria.class);
-        when(criteria.getNumber()).thenReturn(fibonacciCriteriaMockDTO.number);
-        return criteria;
-    }
-}
 @Builder
 class FibonacciCriteriaMockDTO {
@@ Line 496: / Line 449: @@
 </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>