|
23 | 23 | - [Handling Errors in Integration Tests](#handling-errors-in-integration-tests) |
24 | 24 | - [Connecting external tools to the shared Canton instances](#connecting-external-tools-to-the-shared-canton-instances) |
25 | 25 | - [Testing App Upgrades](#testing-app-upgrades) |
26 | | - - [Testing from a custom canton instance] |
| 26 | + - [Testing from a custom canton instance](#testing-from-a-custom-canton-instance) |
27 | 27 | - [Deployment Tests](#deployment-tests) |
| 28 | + - [Helm checks](#helm-checks) |
| 29 | + - [Pulumi tests](#pulumi-tests) |
| 30 | + - [Pulumi state checks](#pulumi-state-checks) |
28 | 31 | - [CI Without Approval](#ci-without-approval) |
29 | 32 |
|
30 | 33 | # Testing in Splice |
@@ -430,9 +433,47 @@ When writing or debugging Helm tests, it is often useful to run `helm unittest` |
430 | 433 | This produces rendered yaml files under a local `.debug` folder |
431 | 434 | that can be inspected to understand errors or determine the correct paths for assertions. |
432 | 435 |
|
433 | | -### Pulumi checks |
| 436 | +### Pulumi tests |
434 | 437 |
|
435 | | -Our pulumi checks are based on checked in `expected` files that need to be updated whenever the expected deployment state changes. |
| 438 | +We use [jest](https://jestjs.io/) for unit tests in Pulumi projects. With these tests we aim to cover |
| 439 | +more complex parts of the deployment implementation and resource definitions. To do the latter we |
| 440 | +recommend using techniques described [here](https://www.pulumi.com/docs/iac/guides/testing/unit/). |
| 441 | +These tests are meant to be fast as they are run both in CI and in pre-commit hooks. |
| 442 | + |
| 443 | +#### Running tests |
| 444 | +To run unit tests from all Pulumi projects run `make -C $SPLICE_ROOT cluster/pulumi/unit-test`. |
| 445 | +Any more specific run requires using NPM directly. To do that the following prerequisites must be met: |
| 446 | +1. build the Pulumi codebase `make -C $SPLICE_ROOT cluster/pulumi/build` |
| 447 | +1. navigate to the root package with `cd $SPLICE_ROOT/cluster/pulumi` |
| 448 | + |
| 449 | +To run all tests from one or more Pulumi projects execute the following command. |
| 450 | +``` |
| 451 | +npm exec -- jest --selectProjects <project> [project]... |
| 452 | +``` |
| 453 | +Specific suites are selected by passing one or more patterns as positional arguments. For example |
| 454 | +the following matches `$SPLICE_ROOT/cluster/pulumi/common/src/retries.test.ts` but also any suite |
| 455 | +that contains `retries` in its path. |
| 456 | +``` |
| 457 | +npm exec -- jest retries |
| 458 | +``` |
| 459 | +Lastly, individual tests can be filtered using the `--testNamePattern` or `-t` for short as shown |
| 460 | +in the following example: |
| 461 | +``` |
| 462 | +npm exec -- jest -t "retry runs the action again if it fails with an exception" |
| 463 | +``` |
| 464 | +All the above ways of filtering tests can be combined to achieve the desired run. More information |
| 465 | +on jest CLI can be found [here](https://jestjs.io/docs/cli). One might also opt for an IDE extension. |
| 466 | + |
| 467 | +#### Adding new tests |
| 468 | +A new test can be added to an existing `*.test.ts` file or to a new `<module>.test.ts` suite where |
| 469 | +`<module>.ts` contains the unit to be tested. These suite files lie next to the module files which |
| 470 | +they cover. Please see the [jest "getting started"](https://jestjs.io/docs/getting-started) guide |
| 471 | +for tips on how to write tests. The type definitions for jest come from the `@jest/globals` |
| 472 | +package usage of which is described [here](https://jestjs.io/docs/getting-started#type-definitions). |
| 473 | + |
| 474 | +### Pulumi state checks |
| 475 | +To make sure that the impact of changes in the Pulumi resource definitions is well understood we |
| 476 | +rely on checked in `expected` files that need to be updated whenever the expected deployment state changes. |
436 | 477 |
|
437 | 478 | Please run `make cluster/pulumi/update-expected` whenever you intend to change Pulumi deployment scripts in a way that alters deployed state. |
438 | 479 | Compare the diff of the resulting `expected` files to confirm that the changes are as intended. |
|
0 commit comments