Skip to content

[DevEx]: Standardize testing approach for asserting API errors via pinia actions #1321

@itsalaidbacklife

Description

@itsalaidbacklife

Improvement Summary

We should create and apply a standardized approach to verifying that the API responds with expected errors

Detailed Description

It is sometimes necessary to verify that the API responds with an expected error for specific requests e.g. for requesting to make an illegal move. Our approach to this has generally been to hijack the app's pinia store and then to call a method on it to make the request, asserting that it responds with an expected error. Here is an example in 3_threes.spec.js:

      cy.window()
        .its('cuttle.gameStore')
        .then(async (store) => {
          try {
            await store.requestResolveThree(Card.THREE_OF_DIAMONDS.id);
            cy.then(() => { // it turns out this is necessary to ensure the assert.fail() call actually fails the test
              // Fail test if backend allows request
              assert.fail('Expected 400 error when requesting to target 3 when resolving three, but came back 200');
            });
          } catch (err) {
            expect(err).to.eq('game.snackbar.oneOffs.three.cannotTargetThree');
          }
        });

So far, our other examples of this all call expect(true).to.eq(false in order to force the failure if the request does not error. Recent exploration in #1320 has shown that we actually need the cy.then() wrapper around the assert.fail() call to ensure that this actually fails the test. Otherwise cypress mishandles the promise chain and will show the failing assertion in the command log, but still pass the test.

  • We should update all the other calls around these asserted API failures to utilize cy.then() same as above
  • If possible, we should consider creating a custom command to call a specific pinia function and assert that it errors with an expected error string

Metadata

Metadata

Assignees

No one assigned

    Labels

    dev experienceImprovements to the code base that make it easier/better/more enjoyable to contribute to Cuttletesting automation

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions