Black-box testing
Black-box testing evaluates software through externally observable behavior and interfaces without relying on knowledge of its internal implementation.
Unit Testing Principles, Practices, and Patterns
A testing technique that evaluates software through externally observable behavior without relying on knowledge of its internal implementation.
- How it is used
- Guides unit tests toward user-relevant outcomes instead of implementation details.
- How deep it goes
- Defines the principle, contrasts it with white-box testing, and demonstrates refactoring a structural test into an outcome test.
- Examples
- Uses MessageRenderer tests that inspect sub-renderers, source code, or produced HTML.
- What you can do after
- Diagnose brittle tests and rewrite them around externally observable results.
Read how Unit Testing Principles, Practices, and Patterns explains black-box testing →
Write Powerful Rust Macros
Black-box testing evaluates software through externally observable behavior and public interfaces without relying on implementation details.
- How it is used
- Verifies a procedural macro’s promised public behavior through the same API its users call.
- How deep it goes
- Defines outsider-focused testing and develops a compiling builder use case, while deferring detailed internal-output checks to white-box tests.
- Examples
- Uses a derived empty struct whose generated `builder().build()` call must compile and return the struct type.
- What you can do after
- Apply it via Rust tests to validate generated public APIs with happy-path and selected failing compilation cases.
Read how Write Powerful Rust Macros explains black-box testing →
Functional Design and Architecture: Examples in Haskell
Black-box testing evaluates software through externally observable behavior without relying on knowledge of its internal implementation.
- How it is used
- Uses public interfaces to reduce project risk by checking observable behavior against functional or nonfunctional requirements.
- How deep it goes
- Defines the interface boundary and contrasts testing modes, but stops short of prescribing implementation-aware cases or detailed test design.
- Examples
- Uses public interfaces, observable results, functional requirements, nonfunctional requirements, and integrated application parts as testing targets.
- What you can do after
- Evaluate functional and nonfunctional requirements through public interfaces and recognize when architecture or additional testing is needed.
Read how Functional Design and Architecture: Examples in Haskell explains black-box testing →
Learn Go with Pocket-Sized Projects
Closed-box testing evaluates a software system from outside its implementation, typically through its externally accessible interface.
- How it is used
- Validates client-visible behavior through a public API while protecting tests from internal implementation changes.
- How deep it goes
- Explains external package layout, visibility boundaries, output assertions, and added cases, but not detailed testing theory.
- Examples
- Uses a logger output example and habit-creation checks for validation results, generated fields, and invalid-input errors.
- What you can do after
- Apply it via Go tests to verify exported behavior without coupling assertions to private implementation details.
Read how Learn Go with Pocket-Sized Projects explains black-box testing →
Learn AI-Assisted Python Programming, Second Edition
Closed-box testing is software testing that evaluates externally observable behavior without relying on knowledge of the implementation's internal structure.
- How it is used
- Tests functions or entire programs by varying inputs and checking outputs against specified behavior.
- How deep it goes
- Explains input-output testing and contrasts implementation-independent cases with code-guided cases, without specifying a formal test-design method.
- Examples
- Uses traffic analysis, palindrome checks, maximum finding, longest-word ties, doctests, and artificial files as testing examples.
- What you can do after
- Diagnose/debug generated functions by designing behavioral tests before relying on implementation-specific analysis.
Read how Learn AI-Assisted Python Programming, Second Edition explains black-box testing →
Object-Oriented Software Design in C++
A testing approach that evaluates software through observable inputs and outputs without examining its internal implementation.
- How it is used
- Uses observable behavior to verify that an application meets functional and nonfunctional requirements.
- How deep it goes
- Defines external tests through inputs, actions, and expected results, without examining implementation internals.
- Examples
- Uses book-entry and repository-search behavior, plus specified input actions and expected results.
- What you can do after
- Evaluate whether application behavior matches stated requirements through externally observable tests.
Read how Object-Oriented Software Design in C++ explains black-box testing →
Related concepts
- contractuses · An API contract is a specification of the operations, data, and behavioral expectations that govern interactions between software components.
- open-box testingcontrasts with · Open-box testing is a software-testing technique that examines a program’s internal implementation to identify likely failures and design structure-specific tests.
- white-box testingcontrasts with · White-box testing is a software testing technique that evaluates behavior using knowledge of the software’s internal implementation, structure, or execution paths.
- compilation testincludes · A compilation test checks whether source code, including a macro invocation, compiles successfully or fails as expected.
- testkind of · A test is a procedure or check that evaluates behavior using specified inputs or evidence against expected results or criteria.
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.