Testing Principles

Well-designed tests help us build products faster and more reliably. This document provides the basic principles and guidelines for writing tests.

Seven Testing Principles

For a detailed explanation of each principle, see Seven Testing Principles.

• Testing shows the presence of defects.
• Exhaustive testing is impossible.
• Start designing tests as early as possible.
• Defects cluster together.
• The pesticide paradox: repeating similar tests will not uncover new defects.
• Testing is context-dependent.
• The absence-of-errors fallacy: finding and fixing defects is of little value if the system is not used or its functionality does not meet users’ expectations.

F.I.R.S.T. Principles

Follow the F.I.R.S.T. principles when writing unit tests. For details, see F.I.R.S.T Principles.

• Fast: Unit tests should run quickly.
• Isolated: Never write a test that depends on another test.
• Repeatable: Tests should produce the same results every time they run.
• Self-validating: A test should determine for itself whether its output is correct.
• Timely: Write unit tests immediately before writing the production code that makes them pass. This principle aligns with test-driven development (TDD), though it is not always followed in practice.

Unit Tests

Follow the basic guidelines below when writing unit tests. For further guidance, read the JUnit Best Practices Guide.

• Test public methods.
• Mock dependency objects that affect test results.
• Avoid disk-related dependencies wherever possible.
• Do not use network-related dependencies.