An entry point is the public doorway into a unit of work: a function, method, or interface that outside code can trigger. From that invocation, work may cross several functions or modules before producing a noticeable result. The entry point is not necessarily the whole unit; it is where the unit begins. section 1.3 section 1.2
For testing, start at an entry point and inspect an exit point. Exit points are externally visible results: a return value, a state change, or a call to a third-party dependency. A focused unit test invokes one entry point and checks one specific exit point, even when the path between them spans multiple modules. section 1.11 section 1.4
A function can be both doorway and result
A small calculation has sum as its entry point: calling sum("2,3") starts the work. Its returned result is an exit point. If sum also updates a running total or calls a logger, those are additional exit points. Test each visible effect separately rather than treating internal steps as the target. section 1.3 section 4.2
Public does not mean “every function deserves a direct test.” Choose entry points that represent useful work a caller can trigger. Getters and setters without logic usually need no separate test; once they contain decisions, calculations, loops, or other control flow, ensure that logic is exercised through an appropriate unit of work. section 1.3 section 1.9
Async code can hide logical decisions behind fetches, promises, callbacks, timers, or other dependencies. Extract the processing of successful and failed async results into public functions, then use those functions as new entry points. Their inputs can be simulated directly, allowing fast, consistent unit tests while a smaller set of integration tests checks the original async orchestration. section 6.2.1 section 6.6
Extract result handling from a fetch
An isWebsiteAlive function can fetch a page, then delegate to processFetchContent(text) or processFetchError(err). Those extracted functions become entry points: call processFetchContent with matching and nonmatching text, or call processFetchError with an error, without performing a real network request. Prefer returning a value from these functions when possible; it keeps tests simpler than callback-based handling. section 6.2.1 section 6.6
Figure 6.2 Extracting the internal processing logic into a separate unit of work helps simplify the tests, because we are able to verify the new unit of work synchronously and without involving external dependencies.
Use the diagram to see how extracting result-processing logic creates a separately triggerable, synchronous unit while leaving async orchestration at the outer boundary. section 6.2.1
When choosing or creating entry points for tests:
- Invoke a public function that starts useful work, then name the visible result you intend to verify. section 1.3
- Keep a test focused on one exit point, such as a returned value, state change, or dependency call. section 1.4
- Extract pure result-processing logic from asynchronous boundaries when direct async tests become slow or flaky. section 6.2.1
- Use integration tests selectively to confirm the real orchestration between the original entry point and external dependencies. section 6.2.1
