10 Commandments for Unit Testing

Ten Commandments for Unit Testing

  1. Refactor SUT to limit LOC required to setup a unit test
  2. Limit a unit test to 10 LOC or less
  3. Engineer tests so that they fail because of business logic and not setup logic
  4. Test behaviors and NOT implementation details
  5. Unit test business logic and NOT integration concerns
  6. Control test dependencies before they control your tests
  7. Provide descriptive test names
  8. Test only one thing per unit test
  9. Engineer tests so that they’re self-contained and can run in complete isolation
  10. Investigate static classes when tests no longer run deterministically

Referenced: Testing with F#

5 Replies to “10 Commandments for Unit Testing”

  1. found your blog after your dotnetrocks appearance, some interesting reading. Could you provide an example on point 10? is this F# specific?

    1. Hi Luke. A static class that has state regardless if its access modifiers (i.e. public, private, etc.) will stay in memory throughout the duration of an app’s lifespan. As a result, unit tests must provide an implementation for the teardown stage before exiting the test method. This will enable each unit test to execute without previous tests affecting it via the mutations to the static class’ state.

      Hence, the four stages of a test:
      * Setup
      * Test
      * Execute
      * Teardown

      Is that a little clearer?

      1. Thanks for the reply, I think that is clear, so you are taking steps to make sure that the unit test is actually testing the unit of work in isolation, without worrying about if it has already run something against that static class.

      2. I would phrase that differently but yes. It’s important for my unit test to run without any preexisting system state that’s outside of the scope of the unit test itself. In other words, my test’s setup will introduce state into the SUT instead of the SUT already having state that my test either is unaware of or has to adapt to.

        Hence, tests that are reliant on external state to exist before running typically result in fragile tests that become a nightmare to maintain.

      3. I will agree with your wording (mainly because your wordsmithery is much better), thanks for the clarification.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: