What you will learn in Unit Testing Principles, Practices, and Patterns
Chapter by chapter
Concepts explained in this book
- mockingMocking is the practice of creating, configuring, or applying mocks in software tests.
- resistance to refactoringResistance to refactoring is a test-quality attribute measuring whether a test continues to pass when implementation code is restructured without changing behavior.
- classical schoolA unit-testing approach, also called the Detroit school or classical style, that isolates tests from one another while allowing the unit under test to use real collaborator objects.
- London schoolThe London school is a unit-testing approach that isolates the unit under test from its collaborator objects, typically with test doubles.
- test doubleA test double is an object that resembles a production dependency but is simplified to reduce complexity during testing.
- protection against regressionsProtection against regressions is the extent to which a test detects defects that cause previously working functionality to stop working as intended after a change.
- out-of-process dependencyAn out-of-process dependency is a dependency that runs outside the application's execution process and provides access to data or services external to in-memory execution.
- output-based testingOutput-based testing evaluates software by comparing explicitly produced outputs with expected outputs rather than verifying internal interactions.
- integration testAn integration test is a software test that verifies interactions and cooperation between integrated components or subsystems.
- false positiveA false positive is a test failure caused by an implementation change that preserves the required behavior rather than by an actual defect.
- application serviceAn application service is a service that coordinates application operations and connects a functional core with external clients and side-effecting infrastructure.
- implementation detailAn implementation detail is an internal design or coding choice that is not part of software's externally observable behavior.
- unmanaged dependencyAn unmanaged dependency is an out-of-process dependency whose interactions are observable by external systems and that is not fully controlled by the application.
- shared dependencyA shared dependency is a dependency whose internal state is reused or accessible across multiple tests.
- brittle testTest fragility is the tendency of a test to fail when implementation changes without changing the tested behavior.
- functional, stateless philosophyFunctional programming is a programming paradigm that expresses computation through mathematical functions and minimizes hidden inputs, hidden outputs, and mutable state.
- behaviorObservable behavior is the externally detectable functionality and outcome produced by software.
- humble object patternA design pattern that moves complex logic into a testable component while leaving a thin component responsible for difficult-to-test interactions with external systems.
- functional coreA functional core is the part of an architecture that makes decisions through computations with explicit inputs and outputs and minimal side effects.
- mutable shellA mutable shell is the architectural part that handles state changes, side effects, and communication with external systems around a functional core.
- contractThe public API is the set of publicly accessible operations and contracts through which a software component can be used.
- arrange act assert patternA test-structuring pattern that prepares dependencies, invokes the behavior under test, and verifies the resulting outcome.
- communication-based testingA unit-testing style that verifies behavior through interactions and communications between the system under test and its collaborators.
- state-based testingA unit-testing style that verifies the state of the system under test, a collaborator, or an out-of-process dependency after an operation.
- system under testThe system under test is the class, component, or larger unit whose behavior a test exercises and verifies.
- testing pyramidThe Test Pyramid is a testing strategy that recommends a relative distribution of unit, integration, and end-to-end tests, with more tests in lower layers.
- factoryA factory is a creation abstraction that constructs domain objects from input data while encapsulating instantiation or reconstruction logic.
- managed dependencyA managed dependency is an out-of-process dependency that is fully controlled by the application and accessible only through that application.
- controllerA controller is a software component that coordinates work between other components without itself implementing substantial complex or business-critical logic.
- backward compatibilityThe ability of a system or communication contract to remain usable by existing external clients after internal changes.
- fast feedbackFast feedback is the speed with which a test communicates whether the tested software behavior meets expectations.
- black-box testingA testing technique that evaluates software through externally observable behavior without relying on knowledge of its internal implementation.
- value objectA value object is an immutable object identified solely by its content rather than by an individual identity.
- encapsulationEncapsulation is the restriction of direct access to an object's internal state and the bundling of that state with controlled operations.
- inter-system communicationCommunication between an application and an external system across an application boundary.
- test isolationThe property of executing a test independently so that other tests or external influences cannot affect its outcome.
- end-to-end testingAn automated test that verifies a complete user-relevant workflow across the system and its integrated components.
- system boundaryA conceptual boundary separating an application's internally implemented behavior from external systems that interact with it.
- spyA spy is a manually written test double that records or verifies interactions with the system under test.
- volatile dependencyA dependency that requires extra runtime-environment setup or produces nondeterministic results.
- repository patternA repository is an abstraction that provides access to and modification of persisted data for a particular domain object or aggregate.
- database transactionA database transaction is a sequence of database operations treated as a single unit that can be committed or rolled back.
- monitoringLogging is the recording of application events, state, or diagnostic information for later observation or analysis.
- support loggingSupport logging produces messages intended for support staff or system administrators to monitor application behavior.
- internal APIThe non-public operations and contracts through which internal implementation details are accessed within a software component.
- stubA test double that supplies predetermined responses to calls without primarily verifying those interactions.
- branch coverageBranch coverage is a test coverage measure indicating which conditional branches in code are executed by tests.
- code coverageThe ratio of production-code lines executed by at least one test to the total number of production-code lines.
- domain layerThe application layer that contains domain concepts, rules, and business logic independently of external communication and infrastructure responsibilities.
- hexagonal architectureAn architectural pattern that separates domain logic from application services and connects external applications through ports or common interfaces.
- intra-system communicationCommunication between classes or components within the same application.
- CanExecute/Execute patternThe CanExecute/Execute pattern separates a domain operation's precondition checks from the execution of the operation while keeping both decisions in the domain model.
- invariant failureA condition in which software state no longer satisfies a rule that must remain true for the domain or component.
- private dependencyA dependency that is not shared between tests and therefore cannot transmit state between their executions.
- maintainabilityThe ease with which software or tests can be understood, executed, changed, and kept operational.
- test valueTest value is an aggregate estimate of a test's usefulness based on its quality attributes and maintenance burden.
- overcomplicated codeOvercomplicated code is code that combines substantial complexity or domain importance with a large number of collaborators.
- migrationA database migration is an explicit, versioned change that transitions a database schema or its data to a subsequent state.
- reference dataReference data is database data that must be prepopulated for an application to operate and cannot be modified by that application.
- ambient contextAmbient context is a dependency-acquisition pattern in which code obtains a shared dependency through static or globally accessible methods instead of explicit injection.
- assertionAn assertion is a test statement that checks whether an observed result matches an expected condition.
- invariantAn invariant is a condition that must remain true for a software object or component.
- mathematical functionA mathematical function is a computation that maps each input to exactly one output without hidden inputs or outputs and produces the same output for a given input.
- given-when-then patternA test-structuring pattern that divides a test into given, when, and then phases corresponding to setup, execution, and verification.
- teardown functionThe test phase that performs cleanup after execution and verification, such as deleting files or closing external connections.
- object graphAn object graph is a connected set of instantiated objects and the references between them.
- test suiteA test suite is a collection of automated tests evaluated together for a software system or component.
- migration-based database deliveryMigration-based database delivery represents database schema changes as ordered migrations applied incrementally over time.
- state-based database deliveryState-based database delivery represents the desired database schema as a complete target state and updates databases to match it.
- fail-fastA software design principle that detects and reports invalid conditions as early as possible during execution.
- trivial codeTrivial code is code with little complexity or domain significance and few or no collaborators.
- abstractionAn abstraction is a representation that captures common behavior across multiple implementations while hiding implementation-specific details.
- data migrationData motion is the transfer, transformation, or relocation of existing data required during a database change.
- application databaseAn application database is a database accessed exclusively by a particular application and hidden from direct access by external systems.
- overspecificationA testing anti-pattern in which tests are coupled to implementation details rather than externally observable behavior.
- unit of behaviorA unit of behavior is a cohesive, domain-meaningful piece of externally observable functionality verified by a test.
- active record patternThe Active Record pattern combines a domain object's business logic with its persistence operations against a database.
- domain significanceDomain significance is the importance of code according to the business meaning and consequences of the behavior it implements.
- tell-don't-askThe tell-don't-ask principle advises objects to perform operations on their own data rather than exposing raw data for other objects to manipulate.
- maintenance costA metric that measures how easy tests are to understand, change, and run and the maintenance effort they require.
- PreconditionA precondition is a condition that must hold before an operation can execute while preserving an object's valid state.
- CAP theoremThe CAP theorem states that a distributed data store cannot simultaneously guarantee consistency, availability, and partition tolerance under network partitioning.
- side effectA side effect is an observable state or resource change caused by executing a method in addition to computing a return value.
- cyclomatic complexityCyclomatic complexity is a metric that counts the independent control-flow paths or branching structure in a program or method.
- indirectionAn intermediate abstraction layer that separates a caller from the concrete implementation or solution it ultimately needs.
- infrastructure layerAn application layer containing technical algorithms and code that communicates with external or out-of-process dependencies.
- multiple act sectionThe execution phase of a test in which the operation or workflow under verification is performed.
- constructor methodA constructor is a class member invoked when an object is created to initialize its state.
- accuracyA metric of how reliably a test suite indicates whether the tested functionality is correct or broken, accounting for false positives and false negatives.
- edge caseA boundary or unusual condition in a business scenario that may require distinct behavioral verification.
- referential transparencyReferential transparency is the property that a method call can be replaced by its return value without changing program behavior.
- dependencyA dependency is a component, object, service, or value that code under test relies on.
- audit systemA software system that records organizational visitor entries in sequential flat files.
- white-box testingA software testing method that verifies internal implementation behavior using knowledge of the application's source code or structure.
- implicit inputA hidden input is an implicit dependency on internal or external state that affects a computation without appearing as an explicit argument.
- regressionA regression is a defect in which a feature that previously worked stops working as intended after a change or other event.
- sustainable growthThe ability of a software project to evolve over time without development becoming unmanageably slow or regression-prone.
- code pollutionCode pollution is the addition of production-code elements whose primary purpose is to enable or simplify testing rather than implement application behavior.
- versioningA source control system records, versions, and manages changes to files such as application code and database definitions.
- naming standardA test naming policy is a set of rules governing how tests are named to communicate their scenarios and intent.
- test-driven developmentTest-driven development is a software development process in which tests guide incremental implementation and refactoring.
- valueA value is dependency data that is available from the object's known state and remains unchanged during the operation that consumes it.
- system edgeThe boundary location where an application directly communicates with an external or unmanaged dependency.
- false negativeA false negative is a test result that fails to reveal a defect that exists in the tested functionality.
- in-process dependencyAn in-process dependency is a dependency that executes within the application's process and can provide behavior or data without external communication.
- entropyThe increasing disorder and complexity that accumulates in a codebase as it is changed without sufficient cleanup.
- adapterA design pattern that presents an application's interface over a different interface supplied by an external component or library.
- tautology testA tautology test is a test arranged to always pass or containing assertions with no meaningful semantic check.
- happy pathA successful execution of a business scenario.
- parameterized testingA parameterized test is a test whose logic is executed with multiple sets of input values or expected results.
- test nameA test name is the human-readable identifier assigned to an automated test to indicate the behavior it verifies.
- single responsibility principleThe Single Responsibility Principle states that a class or module should have one responsibility and one reason to change.
- test fixtureA test fixture is an object or external resource placed in a known state for a test to exercise.
- implicit outputA hidden output is an effect of a computation, such as a side effect or exception, that is not represented by its return value.
- test maintenance costThe time and effort required to keep tests correct, runnable, understandable, and aligned with the code they verify.
- dummy test doubleA test double supplied only to satisfy an interface or parameter requirement without participating meaningfully in execution.
- isolationThe isolation attribute is the aspect of unit testing that specifies what a test or system under test must be isolated from.
- anticorruption layerAn architectural boundary that isolates a domain model from the concepts and interfaces of an external system or model.
- call verificationA testing technique that checks whether expected interactions occur with the required multiplicity and whether prohibited interactions do not occur.
- couplingTight coupling is a design condition in which software components depend strongly on one another.
- database sharingA shared database is a database whose data is accessed by more than one application or system.
- foreign keyA foreign key constraint requires values in one database column or set of columns to correspond to valid values in another table.
- sequential testRunning tests one after another so that only one test executes at a time.
- YAGNI principleYAGNI is the principle of avoiding implementation of functionality until it is actually needed.
- longest happy pathA test scenario that exercises the complete workflow through all relevant out-of-process dependencies and produces the maximum relevant side effects.
- business logicThe set of rules and decisions that implement an application's domain-specific behavior.
- domain modelA software model representing the concepts, rules, and behavior of an application domain.
- code designA method for structuring software code to achieve desired qualities such as maintainability or testability.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.