possible for these tests to be disputed, because there is no individual source of truth for what the implementation should be doing to meet business needs. 

## 8.6.3 Test types 

In this section, we explore how different test stages in the API Test Pyramid apply to an IBM API Connect solution. 

## Unit tests 

The primary question when discussing Unit Testing is what makes up the smallest, testable, self-contained component, as derived from the requirements. A unit test for an API should not call a back-end service. It should not  rely on making requests from outside the API Connect domain and should be executable in any simple IBM API Connect environment. 

The smallest testable unit for API Connect APIs consist of the four components that make an API: 

GLYPH<SM590000> Its address 

GLYPH<SM590000> Its operation 

GLYPH<SM590000> Request data 

GLYPH<SM590000> Response data 

An API has a primary data representation that is called a resource, which is the conceptual mapping to a set of entities. The address  of the resource is displayed as a Uniform Resource Identifier (URI)  which is crucial to making an API call. 

Addresses  will have tests such as; 

GLYPH<SM590000> Does an exposed address return a correct result? 

GLYPH<SM590000> Are unspecified addresses correctly handled? 

GLYPH<SM590000> Are misspelled addresses correctly handled? 

An operation  is the method of a REST API that determines what action to perform on the resource. The four main HTTP verbs that define the operation are; GET (read), PUT (update), POST (create), and DELETE (delete). 

Operation Unit Tests make requests to valid addresses to ensure that the API exposes only the verbs that are outlined in the requirement. This test is simply about operation exposure. 

Simple security tests might also be applicable here like the absence of tokens, client IDs, or certificates for secure endpoints. But they are unlikely to include more advanced tests such as OAuth, which would be more applicable in integration tests as multiple calls are needed. 

Request data  normally refers to a list of headers and the body of data that is passed with an operation to an address. Tests at this level focus on whether the correct data is provided, the correct headers are used, and that incorrect headers or malformed data are handled correctly. 

Response data  normally refers to how the resource call will respond to the request. The data usually includes a status code, headers, and a body. Tests at this level aim to ensure that valid and expected output is received when certain requests are passed into the system. 

Additional tests will be used for the handling of both successful and failure scenarios. 

The simplest unit test topology is shown in Figure 8-20 on page 565. 

