Welcome to intercom_test’s documentation!¶
Contents:
Using This Package¶
intercom_test provides InterfaceCaseProvider
to iterate over test cases defined in YAML files. With the additional use of a
case_augmenter – either an HTTPCaseAugmenter,
a RPCCaseAugmenter, or your own class
derived from CaseAugmenter – the
InterfaceCaseProvider can add more data
from a different directory to any test case; this supports decoupling a service
provider’s implementation details necessary to passing the given test case from
the request and response information needed by both the consumer and the
provider.
What It Looks Like In Practice¶
Example directory tree for using intercom_test
The intercom_test package does not make many requirements of the
directory structure for the project using it, but here is one example of how a
project could be structured to use intercom_test.
This package has no direct concern with the src folder. Within the test
folder, this example project has split the data managed by intercom_test
into component_interfaces and component_test_env. The structure,
relationship, and usage of these two folders are described below.
In this example, the component_interfaces contain both a main test case
file, ($PROJECT/test/component_interfaces/service.yml) and also an
extension file ($PROJECT/test/component_interfaces/service/ext-1.yml),
which will be combined into a single set of test cases by intercom_test.
Any additional .yml files added to the $PROJECT/test/component_interfaces/service
folder will also be read as additional test cases for service. Typically,
the component_interfaces folder would be shared with the projects intending
to consume this service via some version control mechanism like a Git submodule
or a Subversion externals definition. When constructing an
InterfaceCaseProvider with the
example_project directory as the current directory, the first argument
should be "test/component_interfaces" and the second argument "service"
(indicating both the service.yml file and all files matching
service/*.yml).
Additionally, the component_test_env subfolder contains information
necessary for testing the service-provider, but which doesn’t affect the
component interface – database fixtures, data for mocking external services,
etc. Within this folder, the augmentation data for the “service” is the set
of YAML (.yml) files located in the service folder; it is important to
note that the augmentation data will come from all files within the given
folder, so having a separate folder for each interface is probably wise. The
path to pass when constructing one of the standard
CaseAugmenter subclasses would therefore be
"test/component_test_env/service". Since this information is only important
for testing the provider and is tightly coupled to the provider implementation,
the entire component_test_env folder should probably be a part of the
service provider’s source code repository and not shared with service consumers.
This example only contains one such file, named feature-1.yml, but as many
augmentation files as desired can be created, though there is a restriction
on augmenting a single test case in multiple separate files.
So, assuming this project represents some kind of HTTP API, the most logical
way to create the InterfaceCaseProvider
for this directory structure is:
from intercom_test import InterfaceCaseProvider, HTTPCaseAugmenter
...
def get_interface_case_provider():
return InterfaceCaseProvider(
"test/component_interfaces", "service",
case_augmenter=HTTPCaseAugmenter("test/component_test_env/service")
)
...