OwenWiki

User Tools

Site Tools

Trace:
technology:opinions:abiasedguidetounittests

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
technology:opinions:abiasedguidetounittests [2021/09/06 22:00] – [Writing Honest and Brittle Tests] Owen Mellematechnology:opinions:abiasedguidetounittests [2021/09/06 22:52] (current) – Owen Mellema
Line 1: Line 1:
 ====== A Biased Guide to Unit Tests ====== ====== 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 ===== ===== 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.  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 //Feed packaged input into SUT
-FibonacciResponse packagedOutput = Fibonacci.fib3(fibonacciCriteria);+FibonacciResponse packagedOutput = Fibonacci.fib(fibonacciCriteria);
  
 //Create a packaged expected output. //Create a packaged expected output.
Line 356: Line 357:
 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**. 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 ===== ===== 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. 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.
Line 361: Line 370:
 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. 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.
  
-==== Paradigms ==== +==== Using Given-When-Then Correctly ====
- +
-=== Given-When-Then ===+
 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 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. 
  
Line 405: Line 412:
 } }
 </code> </code>
- +==== Effective abstraction ==== 
-=== Parameterized Tests === +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. 
-Another nice way of writing tests is to use parameterized tests. These allow you to test an entire set of data against a simple test case. The problem with using this paradigm is that it can lead to tests that are almost impossible to read. Good practice can, however, prevent this. +  * Do as little packaging in your setup methods as possible. Instead, move the heavy lifting of packaging to dedicated private methods, like this:
- +
-The best parameterized tests define both the inputs and the outputs in the arguments. I think it is better to define a single output for each test, but there's nothing objectively wrong about having more than one output defined. +
- +
-{{ :technology:opinions:in-pt.jpg?600 |}} +
- +
-Here's an example:+
 <code:java> <code:java>
-static Stream<Arguments> outputInputPairs() { +void init() { 
-    return Stream.of( +    criteria = createMockCriteria(0);
-            Arguments.of(0, 0), +
-            Arguments.of(1, 1), +
-            Arguments.of(2, 1), +
-            Arguments.of(3, 2), +
-            Arguments.of(4, 3), +
-            Arguments.of(5, 5), +
-            Arguments.of(6, 8), +
-            Arguments.of(7, 13), +
-            Arguments.of(8, 21), +
-            Arguments.of(9, 34), +
-            Arguments.of(10, 55) +
-    );+
 } }
  
-@ParameterizedTest +private FibonacciCriteria createMockCriteria(int number)
-@MethodSource("outputInputPairs") +
-void correctOutputForInput(int input, int output)+
 { {
-    //Package input +    FibonacciCriteria criteria = mock(FibonacciCriteria.class); 
-    FibonacciCriteria fibonacciCriteria = mock(FibonacciCriteria.class); +    when(criteria.getNumber()).thenReturn(number); 
-    when(fibonacciCriteria.getNumber()).thenReturn(input); +    return criteria;
- +
-    //Feed packaged input into SUT +
-    FibonacciResponse packagedOutput = Fibonacci.fib3(fibonacciCriteria); +
- +
-    //Extract output from packaged output. +
-    int actualOutput = packagedOutput.getResult(); +
- +
-    //Assert that the actualOutput matches what we expect +
-    assertEquals(output, actualOutput);+
 } }
 </code> </code>
- +  * If you need more than one parameter in your setup method, consider using a DTO with a builder to increase comprehension.
-==== Effective abstraction ==== +
-Here's a few ideas for cleaning up your tests with abstraction. +
-  * 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> <code:java>
-@Nested +void init() { 
-class FibonacciTestGWT { +    criteria = createMockCriteria(FibonacciCriteriaMockDTO 
-    FibonacciCriteria criteria; +        .builder() 
-    FibonacciResponse response; +        .number(0) 
- +        .build()); 
-    @Nested +} 
-    class GivenAnIOf0 { +         
-        @BeforeEach +private FibonacciCriteria createMockCriteria(FibonacciCriteriaMockDTO fibonacciCriteriaMockDTO) 
-        void init() { +{ 
-            createMockCriteria(0); +    FibonacciCriteria criteria = mock(FibonacciCriteria.class); 
-        } +    when(criteria.getNumber()).thenReturn(fibonacciCriteriaMockDTO.number); 
- +    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) 
-<code:java> 
-@Nested 
-class FibonacciTestGWT { 
-    FibonacciCriteria criteria; 
-    FibonacciResponse response; 
  
-    @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 @Builder
 class FibonacciCriteriaMockDTO { class FibonacciCriteriaMockDTO {
Line 535: Line 449:
 </code> </code>
   * Don't abstract away the actual calling of the SUT. After all, that's the most important part.   * 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>
technology/opinions/abiasedguidetounittests.1630965603.txt.gz · Last modified: 2021/09/06 22:00 by Owen Mellema