TestHarness<T>
is a type from package:conduit_test
that handles the initialization of your application under test. It is often subclassed to add application-specific startup tasks, like seeding a database with test users or adding OAuth 2.0 clients. A test harness is installed at the beginning of your test's main
function.TestHarness.install
is invoked, it installs two callbacks that will start your application in 'test mode' when the tests start, and stop it after the tests complete. An application running in 'test mode' creates a local HTTP server and instantiates your ApplicationChannel
on the same isolate as your tests are running on. This allows you to reach into your application channel's services to add test expectations on the state that the services manage.configurationFilePath
is config.src.yaml
config.src.yaml
file must have the same structure as your deployment configurations, but values are substituted with test control values. For example, database connection configuration will point at a local test database instead of a production database. For more details on configuring an application, see this guide.install
method calls setUpAll
and tearDownAll
from package:test
to start and stop your application. You can manually start and stop your application by invoking TestHarness.start
and TestHarness.stop
. However, this is not recommended because onSetUp
and onTearDown
will not be called for each test.TestHarness<T>
to provide application customization. (Applications created through the CLI have a suclass in test/harness/app.dart
.) You override callback methods for events that occur during testing, like when the application starts, and before and after each test.install
on your test harness at the beginning of test suite for these callbacks to be called.TestHarness<T>
has an agent
property that is used to execute requests against the application being tested. An Agent
has methods like get
and post
to execute requests and return a response object that can be validated. Its usage looks like this:TestHarness.get
and TestHarness.post
. For additional configuration options, use TestHarness.request
to create a request object that can be further customized by its properties:CodecRegistry
, the same type that manages encoding and decoding for your application logic. When adding a body to a test request, you provide the unencoded value (a Dart Map
, for example) and it is encoded into the correct value (a JSON object, for example). On the inverse side, when validating a response body, the body is already decoded to a Dart type prior to your test code receiving the response.Agent
has defaults values that it applies to requests from it. These values include headers and the request body content-type. For example, you might want all requests to have an extra header value, without having to write the code to add the header for each request.application/json
contentType
. Additional agents can be created for different sets of defaults.hasBody
and hasHeaders
matchers make expectations on the response headers and body easier to write.hasHeaders
matcher takes a map of header names and values, and expects that the response's headers contains a matching header for each one in the map. The value may be a String
or another Matcher
. The response can have more headers than expected - those headers are ignored. If you want to exactly specify all headers, there is an optional flag to pass hasHeaders
.hasBody
matcher takes any object or matcher that is compared to the decoded body of the response. The body is decoded according to its content-type prior to this comparison. For example, if your response returns a JSON object {"key": "value"}
, this object is first decoded into a Dart Map
with the value {'key': 'value'}
. The following matchers would all be true:status='pending'
. For this, there is a partial
map matcher. It behaves similar to hasHeaders
in that it only checks the keys you provide - any other keys are ignored. For example:partial
, you can also ensure that a map doesn't have a key with the isNotPresent
matcher.key3
is not in the map. This is different than verifying key3: null
, which would be true if key3
's value was actually the null value. See the API Reference for conduit_test
for more matchers.POST /employees
, you verify the employee was stored correctly by expecting GET /employees/:id
has the same data you just sent it.TestHarness.channel
. For example, you might execute a Query<T>
against your application's test database:ApplicationChannel
can access, so too can the tests.