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.yamlconfig.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.