9 Matching Annotations
  1. Mar 2021
    1. So the question becomes how many tests are enough?
    2. I am a big advocate of having a complete test base and even erring on the side of caution when it comes to quality engineering and software validation but that is not what we’re talking about here. What we’re talking about here are the tests that we write when we’re doing test-first development and I’m proposing that writing those tests from the perspective of specifying the behaviors that we want to create is a highly valuable way of writing tests because it drives us to think at the right level of abstraction for creating behavioral tests and that allow us the freedom to refactor our code without breaking it.
  2. Sep 2020
    1. Three tests to prove a small piece of behavior. Although it might seem overkill for such a small feature, these tests are quick to write—that is, once you know how to write them
  3. Jul 2020
  4. May 2020
  5. Nov 2019
    1. I should also add that I'm in favor of relying more heavily on integration testing. When you do this, you need to unit test fewer of your simple components and wind up only having to unit test edge cases for components (which can mock all they want).
    1. Often, if you are writing a test that amounts to “it does what it does”, or “it does exactly this, which happens to be duplicated in the application code”, then the test is either unnecessary or too broad.
    2. Here are three rules of thumb I use to determine that something is not worth testing:Will the test have to duplicate exactly the application code? This will make it brittle.Will making assertions in the test duplicate any behavior that is already covered by (and the responsibility of) library code?From an outsider’s perspective, is this detail important, or is it only an internal concern? Can the effect of this internal detail be described using only the component’s public API?