System boundary

As explained in Unit Testing Principles, Practices, and Patterns

A conceptual boundary separating an application's internally implemented behavior from external systems that interact with it.

A system boundary separates behavior implemented inside an application from interactions with external systems. Internal communications are implementation details; externally visible effects are observable behavior. section 5.5

Classify communications by where they occur and whether their effects can be observed:

• Intra-system communication occurs between classes inside the application and should not normally be verified with mocks. section 5.5
• Inter-system communication crosses the application boundary and belongs to observable behavior when its side effects are visible externally. section 5.5
• Interactions with external systems accessible only through the application remain implementation details when their effects cannot be observed externally. section 5.4

Figure 5.14. Communications with an out-of-process dependency that can’t be observed externally are implementation details. They don’t have to stay in place after refactoring and therefore shouldn’t be verified with mocks.

Use the figure to distinguish externally observable communications from out-of-process interactions that remain implementation details. section 5.4

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes

Classifies intra-system and inter-system communication, including the exception for externally inaccessible side effects.

Examples

Contrasts class-to-class calls, visible external interactions, and unobservable out-of-process dependencies.

What you can do after

Evaluate whether a communication should be asserted with mocks by checking its boundary crossing and externally visible side effects.

How it connects

Connects application boundaries with observable behavior, mocks, unit testing, and test fragility.

liveBookmanning.com

Read Unit Testing Principles, Practices, and Patterns on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Architecture Modernization: Socio-technical alignment of software, strategy, and structureA boundary is a defined partition that separates a coherent area of domain behavior, responsibility, or model from other areas.
• 

  liveBookmanning.com
  Effective Platform EngineeringA domain boundary is a defined separation that limits the responsibilities, capabilities, and interactions of a business or technical domain.
• 

  liveBookmanning.com
  Think Like a Software Engineering ManagerA professional boundary is a limit that defines appropriate expectations, availability, and interactions within a professional role and between work and personal life.
• 

  liveBookmanning.com
  Google Anthos in ActionA service boundary is the defined separation around a service's responsibilities, data, and independently deployable behavior.

Compare how 5 books explain system boundary →

Related concepts

• abstractioncontrasts with · Abstraction is a simplified representation that exposes relevant properties or behavior while omitting lower-level details unnecessary for a given purpose.
• software design EventStormingused by · Software design EventStorming is a collaborative modeling technique that explores domain events and processes to inform software structure and behavior.
• big picture EventStormingused by · Big picture EventStorming is a collaborative format for exploring a broad business domain and identifying its domains, subdomains, and complexity.

This explainer was generated by Manning's knowledge graph from the text of Unit Testing Principles, Practices, and Patterns. The section links point to the parts of the book it draws on.