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:03] – [Skipping the Extractor] 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 369: 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 413: 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 543: 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.1630965821.txt.gz · Last modified: 2021/09/06 22:03 by Owen Mellema