Feature: Unit Testing

[calumbell]

The current version of the Open5e website doesn't feature any unit tests. Implementing these will help make the site more robust, and save many potential future headaches.

We do not have a testing library installed, so this will be a two-step process:

1. Select an appropriate testing library (Jest and Vue Testing Library have been suggested as places to start looking)
2. Write unit tests for each page to make sure that;
   2a) Data can be imported from the API
   2b) The page renders correctly

[Sturlen]

I think an end-to-end framework like Cypress would be a better way to test the website. This is great for making sure interactions like "searching for a monster" still work after committing a change. Example of what a test would look like:

describe('searching', () => {
  it('for a bronze dragon', () => {
    cy.visit('https://localhost:3000');
    cy.get('input').type('Adult Bronze Dragon{enter}');
    cy.contains('.search-result a', 'Adult Bronze Dragon').click();
    cy.contains('section', 'The dragon can use its Frightful Presence.');
    cy.contains(
      'section',
      'The dragon exhales lightning in a 90-foot line that is 5 feet wide.'
    );
    cy.contains('section', 'Wing Attack (Costs 2 Actions).');
  });
});

[calumbell]

This looks great. Thanks for the suggestion!

I am planning to work on this issue during the coming week. As this PR only covers getting everything set up with our PR validation and running few very basic tests (ie. did this most recent PR explode the website), there will definitely be some follow-up issues to implement more robust testings.

Aside: in the code above we are testing hard-coded strings against the content of the webpage. My instinct is that we should fetch these strings from the API at run-time. That way if the copy for a particular endpoint changes (ie. if a typo is fixed), it won't break the tests. Any idea whether this possible in Cypress?

[Sturlen]

Aside: in the code above we are testing hard-coded strings against the content of the webpage. My instinct is that we should fetch these strings from the API at run-time. That way if the copy for a particular endpoint changes (ie. if a typo is fixed), it won't break the tests. Any idea whether this possible in Cypress?

Fetching data from the API is doable. Another option is to mock the API itself. The Bronze Dragon example above was more of a random sample to make sure that search itself works and gets you the same result each time.

I'll push my test branch as draft and you can try it out yourself.

[calumbell]

Oh wow, looks like you have already made a lot of progress!

Are you planning to continue working on this issue? If so I can assign it to you. Or is this you handing off your work to date for another dev to build on top of?

[Sturlen]

I plan to keep building. Currently the biggest roadblock is Cypress has to be run through npx every time, instead of being installed normally.

If anymore more experienced with Cypress wants to help with this, then I'd be very open to that.

[calumbell]

Awesome. If you are planning to continue working your way through this issue i'll assign it to you so that people know who to talk to if they'd like to help out.

I am no expert on Cypress, but i'd be happy to take a peak and see if I can help out in any way

[calumbell]

Hey @Sturlen, are you still actively working on this issue since hitting a roadblock with Cypress? I was considering looking at the Nuxt Test Utils, but wouldn't want to step on your toes if you were already in the midst of getting something up and running

[Sturlen]

I'm not working on anything else right now so feel free. Biggest hurdle was getting the test framework to work with the current stack, so using nuxt tooling might be the best.