Design Patterns Handbook
  • Introduction
  • Creational Patterns
    • Builder
    • Factory
    • Abstract Factory
    • Factory Method
    • Prototype
    • Singleton
    • Object Pool
    • Revealing Constructor
  • Structural Patterns
    • Adapter
    • Composite
    • Proxy
    • Flyweight
    • Facade
    • Bridge
    • Decorator
    • Private Class Data
  • Behavioral Patterns
    • Template Method
    • Mediator
    • Chain Of Responsibility
    • Observer
    • Strategy
    • Command
    • State
    • Visitor
    • Memento
    • Interpreter
    • Null Object
    • Iterator
    • Middleware
  • Clean Code Patterns
    • Extract Method
    • Clarify Responsibility
    • Remove Duplications
    • Keep Refactoring
    • Always Unit Test
    • Create Data Type
    • Comment to Better Name
    • Consistent Naming
    • If-else over ternary operator
    • Composition over Inheritance
    • Too Many Returns
    • Private to Interface
  • Anti Patterns
    • Big Ball of Mud
    • Singleton
    • Mad Scientist
    • Spaghetti Code
    • It Will Never Happen
    • Error Codes
    • Commented Code
    • Abbreviations
    • Prefixes
    • Over Patternized
    • Generic Interface over Function
Powered by GitBook
On this page
  • When to write unit test
  • Are there any exceptions
  • Are there any excuses

Was this helpful?

  1. Clean Code Patterns

Always Unit Test

PreviousKeep RefactoringNextCreate Data Type

Last updated 5 years ago

Was this helpful?

There is a concept of . It suggests that there should be more unit tests than integration tests. And there should be more integration tests than e2e tests.

When to write unit test

When we should create a unit test?

  • If we follow Test Driven Development, we always start with a test. Most likely, it is going to be a unit test.

  • If we don't follow TDD, we should create a unit test for each unit, a unit is a method or function.

  • When we are fixing a bug (and no tests are failing), we should first replicate that by in a unit test.

Are there any exceptions

What are the exceptions? There can be a reason to not to write a unit test. The easy identifier of such a situation is length of setup for a unit test. If we have to mock half of the application, and our setUp method has a lot of lines, lets say more than 50, we might face to code which is not testable, it contains too many static initialization blocks and too many final keywords. We need to use tools like PowerMock, that can modify byte code and make the code testable by force.

Are there any excuses

Many.

One excuse I was personally fighting with was, "Should I write unit tests for code that might not be used, because it is just PoC or it is just a new product that have very low chance of success?". Why did I asked this question? Because I have spend really a lot of time to make sure our code is nearly 100% covered by tests. We have spent a lot of time by implementing all the business logic. Keep high test coverage required extra effort. Then a project was thrown away. All that work vanished for ever.

Why to bother with tests anyway? First logical implication is that we never know what project is going to stay with us and what project is thrown away. But more importantly, we are professionals and we need to keep output of our work at the top level. We always need to create tests keeping test pyramid in mind. More unit tests than integration tests and more integration tests than end to end tests.

test pyramid