Ch. 6 Testing Services and Systems
As discussed in the previous chapter, Jellyfish will generate services and systems that contain sub-projects that can be used to perform black box testing of services and systems. This chapter will discuss how to run and implement these tests.
Testing Services
When we modeled the SoftwareRequestService
, we created Cucumber feature files in the src/test/gherkin/
directory of the
SD project. The file SoftwareRequestService.processRequest.feature
is the feature file that contains the Gherkin
scenarios for testing the processRequest
scenario of the SoftwareRequestService
service.
When the service project for the SoftwareRequestService
is generated, the sub-project
com.helpco.helpdesk.softwarerequestservice.tests
will automatically be configured to reference this feature file. The
sub-project will reference any feature file whose name starts with SoftwareRequestService
. This
com.helpco.helpdesk.softwarerequestservice.tests
sub-project will produce an executable application when it is built.
We can build the project with the command ./gradlew clean build
.
The build
directory of the sub-project will be populated after the project is built. This directory contains a
ZIP file that contains the testing application. The ZIP file contains everything necessary to test the actual
SoftwareRequestService
. We can run the tests by running the start script inside the bin/
directory. Since the tests
are run as a separate process, we need to start the actual SoftwareRequestService
service before starting the tests, or
they will fail.
The distribution ZIP also contains a resources/
directory. Within this directory is a directory structure that mirrors
the package of the SoftwareRequestService
. In this case, this structure is com/helpco/helpdesk/
. We can find the
feature files actually used by the service in this location. Note that only the feature files for the service-under-test
are included. Feature files for other services or systems are omitted.
Implementing Tests
By default, all tests are not implemented. Product teams must implement these tests by implementing
Cucumber step definitions. These definitions turn the phrases
in feature files into executable code. Step definitions can be stored in the package
com.helpco.helpdesk.srs.tests.steps
within the tests sub-project.
Step definitions and multiple classes
Step definitions are really just methods with @Given, @When, @Then, etc annotations. All step definitions do not have
to be implemented in the same class. Steps can be broken into multiple classes for ease of development.
Testing Systems
Systems are tested the same way. Our SoftwareStore
system also contains a feature file named
SoftwareStore.handleInstallationRequest.feature
. Unlike tests for individual services, tests for systems require all
services of a system to be running.
We can run the tests for our SoftwareStore
system by running the start script generated in the
com.helpco.helpdesk.softwarestore.tests
sub-project of the system project. In many cases, we run the start script
for the entire system to easily start all the services required for the system level tests.
Step definitions for system tests are implemented in the exact same way as service tests.