A data manipulation routine receives structured data, transforms it, and returns structured data without directly managing persistent application state. This boundary keeps business intent separate from low-level collection work, so logic can stay concise instead of becoming tangled in data-access details. section 10.5 section 14.0
Design a custom routine through four practical moves:
- Discover the most convenient function signature by writing the intended call before implementing it. section 14.5
- Write a unit test with representative input and expected output, then compare the resulting data. section 6.1
- Describe the behavior in plain English and give the routine a name that conveys business intent. section 14.5
- Implement the least generic utility that solves the problem, hiding low-level operations such as reduce inside it. section 14.5
The contrast appears at the state boundary. A routine such as Library.addMember returns a new map and is straightforward to test; System.addMember retrieves and commits state, so its test must inspect the state afterward. The stateful shell remains, but the data-transforming core is easier to isolate. section 6.4
Joining results from two sources
A search endpoint can fetch database rows and external book information, index each array by a chosen field, merge the maps, and return the merged values. The reusable joinArrays(a, b, keyA, keyB) routine keeps that manipulation out of the endpoint’s business logic and can be tested with two input arrays and an expected joined result. section 11.6
Listing 6.3 The general pattern of a data-oriented test case
var dataIn = {
// input
};
var dataOut = {
// expected output
};
_.isEqual(f(dataIn), dataOut);
Use the input-output test pattern as a compact template for routines that do not manage persistent state. section 6.1
