chore: test setup

[MiroDojkic]

Test setup

This PR adds a test setup that deploys infrastructure stacks using Pulumi Automation API and then runs tests using the NodeJS native test runner.

Changes

• Added a test runner command that runs all tests (tests/**/*.test.*): npm test.
• Added stack deploy and destroy automation that can be performed before and after all tests in a test suite.
• Added a test suite for the WebServer component that deploys it with minimal configuration. Test asserts that healthcheck endpoint returns 200

Disclaimers

• If multiple tests try to deploy VPC to the same AWS account, using the Project component, deployment will throw an exception due to trying to take more than the maximum number of elastic IP addresses (eips).

[MiroDojkic]

@droguljic to simplify maintenance, we could move examples to tests, since we'd like to test each component, and integration between components anyway.
What do you think?

[droguljic]

In my opinion, examples serve the different purpose and having them is definitely valuable. I agree that we should test each component and integration between them.
In current state I'm not sure that examples could be just copied and run as is, if I remember correctly there was some issue when I tried to do so.
My suggestion would be to reference examples in tests and in that way we ensure that they are reproducible and on the other hand we test component and integration, while leaving them to serve their purpose.

[MiroDojkic]

That makes sense, but it might also become complex to maintain. If we're looking to match examples with tests, we'll either introduce noise to examples by having redundant examples, or to tests by trying to make use of a single example to test many properties and assumptions.

We could also have examples only serve as examples, and rely on test setup to provide deployable stacks. It definitely doesn't make sense to have deployable stacks in both tests and examples, as that's a lot of surface to maintain (upgrades, testing that it works, updating API...).

[droguljic]

Continuing on the offline conversation, the current idea is to keep complex uses cases that test integration between many components as part of examples, and more simpler ones as part of tests.

[MiroDojkic]

@droguljic can you review the high-level approach to testing and test setup?

[mbareta]

Are there any advantages of using node test vs jest? Maybe we'd want to set default test runners across the company and show by example. This is a question, I don't know which is better or better-suited.

[MiroDojkic]

There are differences. One big preference that I have is using test runners that use native execution environments such as node's native test runner, ava, or tape.

Generally speaking, jest pulls a lot of unnecessary dependencies and is slower. Depending on the use case, extra features can be helpful or not.

Where do you find value in standardizing a test runner for unit and integration tests?

[mbareta]

The intent was to standardize the test runners across projects. But if native runners will perform better, then we should stick with those.
My idea was to use test runners which we would be able to recommend to people as a part of the CoP.

[MiroDojkic]

Oh yeah, I got that part, but I'm not actively developing for some time so I was genuinely curious to hear your thoughts. Might be worth exploring.
Let's bring it up during some future CoP thread or sync.

[MiroDojkic]

@mbareta @droguljic I addressed your comments.
I also edited commit messages to switch to conventional commits.