[CORE FEATURE] Devise testing strategy (unit, integration, etc.) and incorporate into CI/CD workflow

[awpala]

No description provided.

[ashiquem]

What: Evolving decision framework for testing, enabling development of high quality reliable software

Required outcomes:

• define definition of done for each feature from testing perspective eg. code coverage for unit tests, risk based testing for functional tests etc
• establish quality gates: define important metrics for blocking builds if any, code coverage, code smells other static analysis etc
• tool selection: adopt a tool selection framework and decide on current tools necessary, eg functional,unit testing tools
• monitoring and reporting(stretch): ensure developer has means of assessing product quality through metrics report eg assess if current CI tools enable reporting of test metrics in the best manner, if we need dashboards

[disposedtrolley]

Agreeing on some tenets on software testing and quality will serve us well, those are some great discussion points @ashiquem!

establish quality gates: define important metrics for blocking builds if any, code coverage, code smells other static analysis etc

I like to double-down on checks that are difficult to implement if we don't do it early on. Linters and formatters are one example of this; we should think about enforcing Prettier and ESLint checks as a prerequisite for merge. Diffs become much, much easier to parse when we're all coding in the same style. There's nothing worse than a one line change that shows as 10 files modified because an editor decided to change the number of spaces for indentation!

tool selection: adopt a tool selection framework and decide on current tools necessary, eg functional,unit testing tools

There'll be a lot of flux in the codebase as the MVP gets built, so ideally we'd want a strategy that allows for rapid change while ensuring the important parts of the application continue to function (the 80/20 rule and critical user journeys play a part in defining what we consider important). Tight feedback loops are what we want to strive for.

To that end, I think we should investigate end-to-end browser testing. These tests will execute against the live application and mimic the interactions of a user and serve as good integration tests. They're more resilient to change than unit tests, and allow us more freedom to refactor code without worrying about changing a whole suite of unit tests. Playwright is a good choice for these tests.

Vercel also deploys PR branches automatically for us (see this PR comment as an example), so we can set up a GitHub Actions workflow (or similar) to execute these tests against the preview environment.

There are a couple of issues that we could PoC out straight away:

1. Adding a GitHub Actions workflow to run Prettier and ESLint on PR branches, and making these a prerequisite for merging the change.
2. Scaffolding out a Playwright spec that navigates to a target URL and makes a dummy assertion on some content on the page. Add this to a GitHub Actions job and feed it the preview URL that Vercel generates.

[awpala]

Agreed to focus on the core feature set; proving that React renders a component is not very valuable here, but proving that a user can interact with the views and post reviews--that's the do the thing thing our thing is supposed to do!

[awpala]

Also +1 for Playwright for E2E and integration testing, we use it at my workplace, and together with RTL they form a killer combo for all things React frontend testing! For anything involving a critical user path through the app/views, that would be a smart move, tooling-wise.

[disposedtrolley]

Also +1 for Playwright for E2E and integration testing

I might give this a try as my next task!

[github-actions]

This issue is stale because it has been open for 60 days with no activity.