diff --git a/docs/content/docs/manage-ecosystem/runs-get.md b/docs/content/docs/manage-ecosystem/runs-get.md index d1367bf2f..7eba88183 100644 --- a/docs/content/docs/manage-ecosystem/runs-get.md +++ b/docs/content/docs/manage-ecosystem/runs-get.md @@ -21,7 +21,7 @@ Use the tables provided to view the options for filtering test results, and for | `--result` | Use the [`--result` option](#more-about-the-result-option) to return test runs based on test run results. You can select more than one result by using a comma-separated list. The `--result` flag cannot be used in conjunction with the `--active` flag. The two flags are mutually exclusive. | | `--active` | Use the `--active` option to query tests that have not finished, so that you can quickly see which tests are currently running. The `--active` flag cannot be used in conjunction with the `--result` flag. The two flags are mutually exclusive.| | `--group` | Use the `--group` flag to get all the test runs associated with the given group name. A custom group name can be assigned to a set of test runs when submitting tests using the [galasactl runs submit](./runs-submit.md) command, otherwise a random group name will be assigned. `--group` can be used with other flags, like `--age`, `--requestor`, and `--result`, to filter test runs as desired, but it cannot be used alongside the `--name` flag. | -| `--tags` | Use the `--tags` flag to get all the test runs that have the given test tags assigned to them. A custom set of tags can be assigned to a set of test runs when submitting tests using the [galasactl runs submit](./runs-submit.md) command. `--tags` can be used with other flags, like `--age`, `--requestor`, and `--result`, to filter test runs as desired. Multiple tags can be supplied by either providing `--tags` with a comma-separated list of tags (e.g. `--tags tag1,tag2,tag3`) or by providing multiple `--tags` flags separately (e.g. `--tags tag1 --tags tag2 --tags tag3`). | +| `--tags` | Use the `--tags` flag to get all the test runs that have test tags assigned to them. A custom set of tags can be assigned to a set of test runs when submitting tests using the [galasactl runs submit](./runs-submit.md) command. `--tags` can be used with other flags, like `--age`, `--requestor`, and `--result`, to filter test runs. Multiple tags can be supplied by either providing `--tags` with a comma-separated list of tags (e.g. `--tags tag1,tag2,tag3`) or by providing multiple `--tags` flags separately (e.g. `--tags tag1 --tags tag2 --tags tag3`). | **Table 2:** The following table shows the options that you can set on the `galasactl runs get` command to display test run results in different formats: diff --git a/docs/content/docs/writing-own-tests/test-result-provider.md b/docs/content/docs/writing-own-tests/test-result-provider.md index 7aaa0daef..08a4f0e41 100644 --- a/docs/content/docs/writing-own-tests/test-result-provider.md +++ b/docs/content/docs/writing-own-tests/test-result-provider.md @@ -4,7 +4,9 @@ title: "Controlling code execution after test failure" As a tester, you may want the ability to access the result so far of a Galasa test at different points during the test lifecycle, to control the execution of code based on that result. -The `ITestResultProvider` can be used to get the test result so far after the first method invokation in a test. It can give you access to if the test is in Passed or Failed state. You can then check the result so far in your test code and choose to call or not call non-test methods based on this. +The `ITestResultProvider` can be used to get the test result so far after the first method invocation in a test. +It can give you access to if the test is in Passed or Failed state. +You can use the state of the test (Passed or Failed) to control how non-test code is run. The annotation `@TestResultProvider` injects a `ITestResultProvider` object into your test class. The Core Manager updates the provider with the test result so far after each `@BeforeClass`, `@Before`, `@Test`, `@After` and `@AfterClass` method. @@ -15,7 +17,9 @@ To use this capability, simply include the lines of code below in your test: public ITestResultProvider testResultProvider; ``` -In the example below, the `@AfterClass` method retrieves the result from the `ITestResultProvider` and checks if it is Failed. If the result is Failed, the method `myCustomCleanupMethod` is called which could contain some diagnostic collection or clean up of resources, which the tester only wants to be run if the test Failed. +In the example below, the `@AfterClass` method retrieves the result from the `ITestResultProvider` and checks if it is Failed. +If the result is Failed, the method `myCustomCleanupMethod` is called. +Running the `myCustomCleanupMethod` generates additional information to help diagnose the cause of the failure and cleans up resources. ```java @AfterClass @@ -27,7 +31,7 @@ public void afterClassMethod() throws FrameworkException { private void myCustomCleanupMethod() { try { - // Some custom cleanup logic that only happens on failures. + // Custom diagnostic collection and cleanup logic that only happens on failures. } catch(Exception ex) { logger.error("Failing while cleaning up in myCustomCleanupMethod()"); // Ignore the problem. diff --git a/docs/content/releases/posts/20250506-v0.41.0.md b/docs/content/releases/posts/20250506-v0.41.0.md index ef6c8721b..a9278672b 100644 --- a/docs/content/releases/posts/20250506-v0.41.0.md +++ b/docs/content/releases/posts/20250506-v0.41.0.md @@ -41,15 +41,15 @@ links: - Managers vetoing method execution changes: - - Managers implementing anyReasonTestMethodShouldBeIgnored will not be called to see whether the manager wants to veto the execution of `@Before` or `@After` methods separately to the test method they surround. Managers will only be asked whether the test method should be ignored or not, which will cause the "before" and "after" methods to also be ignored. + - Managers implementing `anyReasonTestMethodShouldBeIgnored` are no longer asked whether the test method should be ignored before running the `@Before` and `@After` methods. If the test method is ignored, then the `@Before` and `@After` methods are also ignored. - Tests can find out if the test has failed yet: - Test code can ask for a TestStatus provider to be injected into their object. This can be used to find out if the test has failed yet or not, and can be useful when doing complex cleanup of resources allocated during the test. -- 3270 manager now copes with SSCP-LU-DATA: +- 3270 Manager can now process SSCP-LU-DATA: - - Unformatted data screens are now processed and the contents is visible to test applications. + - Unformatted data screens are processed and the contents made available to test applications. - `@ContinueOnTestFailure` annotations: