主要内容：

 

Categories

Fitness functions exist across a variety of categories related to their scope, cadence, result,

invocation, proactivity, and coverage.

Scope: Atomic Versus Holistic

Atomic fitness functions run against a singular context and exercise one particular aspect of the

architecture. An excellent example of an atomic fitness function is a unit test that verifies some

architectural characteristic, such as modular coupling (we show an example of this type of fitness

function in Chapter 4). Thus, some application-level testing falls under the heading of fitness

functions, but not all unit tests serve as fitness functions—only the ones that verify architecture

characteristic(s). The example in Figure 2-3 represents an atomic fitness function: it checks only

for the presence of cycles between components.

For some architectural characteristics, developers must test more than each architectural

dimension in isolation. Holistic fitness functions run against a shared context and exercise a

combination of architectural aspects. Developers design holistic fitness functions to ensure that

combined features that work atomically don’t break in real-world combinations. For example,

imagine an architecture has fitness functions around both security and scalability. One of the key

items the security fitness function checks is staleness of data, and a key item for the scalability

tests is number of concurrent users within a certain latency range. To achieve scalability,

developers implement caching, which allows the atomic scalability fitness function to pass.

When caching isn’t turned on, the security fitness function passes. However, when run

holistically, enabling caching makes data too stale to pass the security fitness function, and the

holistic test fails.

We obviously cannot test every possible combination of architecture elements, so architects use

holistic fitness functions selectively to test important interactions. This selectivity and

prioritization also allows architects and developers to assess the difficulty in implementing a

particular testing scenario, thus allowing an assessment of how valuable that characteristic is.

Frequently, the interactions between architectural concerns determine the quality of the

architecture, which holistic fitness functions address.Cadence: Triggered Versus Continual Versus Temporal

Execution cadence is another distinguishing factor between fitness functions. Triggered fitness

functions run based on a particular event, such as a developer executing a unit test, a deployment

pipeline running unit tests, or a QA person performing exploratory testing. This encompasses

traditional testing, such as unit, functional, and behavior-driven development (BDD) testing,

among others.

Continual tests don’t run on a schedule but instead execute constant verification of architectural

aspect(s), such as transaction speed. For example, consider a microservices architecture in which

the architects want to build a fitness function around transaction time—how long it takes for a

transaction to complete, on average. Building any kind of triggered test provides sparse

information about real-world behavior. Thus, architects build a continual fitness function that

simulates a transaction in production while all the other real transactions run, often using a

technique called synthetic transactions. This allows developers to verify behavior and gather real

data about the system “in the wild.”