Skip to content

CAPI Testing Guide

Tim Hausler edited this page Mar 30, 2017 · 1 revision

Tests

The cloud_controller_ng repo tests are organized in the following manner, from highest to lowest level:

Test Function
CATS ensure that CC changes show up in DEA/Diego/services/etc.
integration ensure that our endpoints produce the correct data when hit (currently the api_doc spec and the integration spec, as of 12/3/15)
acceptance ensure that high-level features within CC work (because of the api_doc_specs acting as integration specs, currently only used for service brokers)
unit ensure that individual objects perform as expected

How to Use Them

Our general pattern is to write the higher-level tests first, and use these tests to drive out further tests.

For example, we might write an api spec (integration spec) first, then use that to drive out the unit tests for messages, actions, models, and preserters we need.

Start with This Test

Generally, the type of high-level test we start with is determined by the story:

  • If we have something to do with pushing apps or binding services or talking to DEA/Diego, we write a CAT to ensure that the app/service/property is present on the DEA
  • If we add an endpoint or change the API, we write an (api doc) integration test to validate that the endpoint takes the expected input and returns the expected response
  • If we add a feature that is not an endpoint (e.g., adding functionality to service brokers), we write an acceptance test to ensure that it works as expected

We use these high-level tests to drive out the unit tests and associated objects we need to make the test pass.

Clone this wiki locally