Testing: Add e2e tests for Sprint template, Sprint creation, & basic Sprint functionality

[jayeclark]

Description

We have a GitHub Actions CI flow that runs automated unit & integration/e2e tests on newly opened pull requests via Vitest as the test. The tests are fairly limited right now - really just proof of concept that unit and integration tests will work.

Are you looking to practice your test-writing skills? Or are you just a wizard at integration/e2e testing who likes helping out on open source efforts? We would love it if you could help us establish some best practices in testing by expanding the initial set of integration tests that are run. We'd like to focus first on Sprints & the Arena since this functionality is not pay gated and does not require any puzzle-solving to access, so is likely to have the highest rate of contributions as the functionality gets built out :).

Background

The 'Arena' section of the app is a place where learners can create weekly sprints to help them practice good habits related to their software development career. The main screen shows your upcoming, current, and completed sprints in chronological order, starting with the most recent one.

Clicking on any one of them will bring you to the individual Sprint view. In this view you can record & view your planning notes, mark daily achievement goals as completed (use Time Travel to submit achievements for previous days if you forgot to record them), and view your position in the leaderboard of the team participating in your sprint.

To create a new sprint, click on "Start a Sprint" in the left-hand navigation panel. You'll have the option to select a Sprint Template from existing predefined templates, Competitors (friends you want to join you in the sprint), and a Start Date. Once you click the 'create' button, you'll be brought back to the main page showing all your sprints.

To create a template for a sprint, click on "Sprint Template". Enter a name for your template, drag & drop achievements to the time of day that you aim to complete them, and click the "create" button to save your template.

Tests

• An authenticated (logged in) user can create a sprint template #452
• An authenticated (logged in) user can create a sprint #469
• Clicking on a sprint displays details about that sprint
• A user can save planning notes in the Plan tab of Sprint details
• A user can report completing an achievement if the sprint is currently active
• A user cannot report achievements for inactive sprints
• A user can report an achievement on an earlier or later day by using time travel
• When a user reports an achievement, their progress is shown in the 'stats' and their position is shown on the leaderboard

Multiple PRs welcome. Splitting up into multiple PRs is highly encouraged for ease of code review! (Maybe try one test at a time.)

Wondering where to start?

tests/integration/login.test.ts contains a basic login test as an example e2e test. You have two options for how to add additional tests:

Option A - you could separate the existing "should allow a user to log in and log out" test into two separate tests, and insert your new tests in between the two. If you do this, it would make sense to rename the test as we are no longer just testing login with it but the whole user flow. Later PRs could refactor this test file to avoid an enormously long test file for authed user behavior.

Option B - you could use the login test as an example and create a new file for each set of related tests. Move the functionality actually related to logging in to the beforeAll stage and the functionality that actually logs out the user to the afterAll stage, then add your tests using a similar format as the it("should allow a user to log in and log out") block. Each test should have three basic sections:

• setup: where you do the steps to set up the scenario you're going to test. (In the existing login test, this is lines 27-31)
• subject under test: you identify what you're actually going to be running the test on. (In the existing login test, this is line 33)
• condition(s): where you check that the subject under test matches the conditions you expect. In the existing login test, this is lines 34-37. We are taking a screenshot for diagnostic purposes if the logout button is not visible (because if logout is not visible, it suggests that login was not successful, and we'd like to see if we can tell why based on what the screen looks like) and also explicitly writing the test that we expect the logout button (subject under test) to not be undefined.

If going this route, you may find that you need to adjust the vitest integration config or script to disable threads, as running tests in parallel could cause issues since multiple tests would be running at the same time, trying to log in and log out the same user. (See section on threads here: vitest features )

Some considerations:

• Start small!
• We probably don't want to be creating infinite sprints or sprint templates. The functionality to delete a sprint or sprint template as an authed user hasn't yet been implemented on the backend (only admins can currently delete sprints), but, it might be a good idea to create the basic function within tests that calls the backend to delete a sprint and to remove oneself from a sprint. (You can comment out the actual api call.) That way, the contributor implementing the code on the backend can uncomment the api call and use the integration test to validate that their backend changes are working!

[jayeclark]

@jeremydthomas Per discussion here, this one is all yours if you want to claim it! Let me know if you want to pair program on anything.