The frontend repo has started to create tests for its component. There are two methodologies of testing:

• Unit/Component testing

• Integration testing

Some of these videos may help to introduce frontend testing as a whole (from 6080 lecs):

• Introduction to testing: https://www.youtube.com/watch?v=bNomuwKoUYw

• Unit/Component testing practical: https://www.youtube.com/watch?v=DthXbNHho9A&feature=youtu.be

And of course, there are more useful resources around the internet!

Unit Testing

Unit testing is basically writing tests for individual components. For the Circles frontend repository, we use Vitest and React Testing Library.

• Vitest - If you ever worked with Jest before (i.e. from COMP1531), it’s basically the same as that except with some marginal small differences. But generally the same methods from jest can be used with vitest. i.e. expect(...).toBeCalledWith(...). The only difference is that whenever you need to call the jest api, replace it with vi. i.e. jest.fn() can be used in vitest with vi.fn() instead,

• React Testing Library (RTL) - RTL is a set of helpers above the Vitest/Jest framework that allows you to manipulate frontend components specifically. It’s commonly used to test frontend actions such as a user clicking a button.

Some useful docs for references:

• Vitest - https://vitest.dev/api/#expect (ps. could be useful to refer to jest API doc aswell https://jestjs.io/docs/expect)

• RTL - https://testing-library.com/docs/react-testing-library/api

So what tests do I write with frontend components?

Like with writing tests as a whole and test driven development, we are ensuring whether the functionality adheres to the software requirements and that it generally covers most of the use case we may encounter. Writing frontend component tests ensures that any changes later on with the codebase ensures that we are still adhering to the software requirements and functionality.

In terms of writing tests for a component themselves, some ideas for test cases includes:

• Testing the input props passed to the component. For example,

  • if a function handler is passed as a prop, would it be called at any point?

  • if a label text is passed, will the component render it?

  • if a toggle state is passed, will it render it initially?

  • if the component will render differently depending on the prop (i.e. passing in a disabled field), will it render in that way?

• Testing the flow of the component - If your testing a bigger component, does it follow a particular flow? i.e. Toggling a switch will disable/enable some buttons.

• Testing the effects when actions are applied to the component - You can also write tests based on the after effects of certain actions. For example, if we have a reset button component, does clicking the reset button actually reset the state?

• Sometimes, you can also tests the style that the component is meant to have. This case is generally not used alot but it can be useful at times. For example, if a button is disabled and it shouldn’t show cursor: pointer, write a tests to ensure that it doesn’t.

• etc (there is many tests ideas depending on the component)…

Mocking

For components that have some dependencies (i.e. redux state, relying on the response from an api endpoint), we may end up requiring to do some mocking of the data, creating ‘fake’ versions of the data. https://vitest.dev/guide/mocking.html

• When mocking axios API responses, we use https://www.npmjs.com/package/axios-mock-adapter i.e. The code below, would mock the /specialisations/getSpecialisations/3778/majors api response payload when a component calls this route.
  
  

  const axiosMock = new MockAdapter(axios); axiosMock.onGet('/specialisations/getSpecialisations/3778/majors').reply(200, { spec: { 'Computer Science': { is_optional: false, specs: { COMPN1: 'Computer Science (Computer Networks)', COMPD1: 'Computer Science (Database Systems)', COMPS1: 'Computer Science (Embedded Systems)', COMPA1: 'Computer Science', COMPJ1: 'Computer Science (Programming Languages)', COMPY1: 'Computer Science (Security Engineering)', COMPE1: 'Computer Science (eCommerce Systems)', COMPI1: 'Computer Science (Artificial Intelligence)' }, notes: 'COMPA1 is the default stream, and will be used if no other stream is selected.' } } });

• When mocking redux state changes (i.e. testing the component with a particular redux state), we have a custom renderWithProviders function that takes in a optional preloaded state for redux
  
  

  const preloadedState = { degree: { programCode: '3778', programName: 'Computer Science', specs: [], isComplete: false } }; describe('SpecialisationStep', () => { it('should render', async () => { renderWithProviders(<SpecialisationStep incrementStep={incrementStepMock} type="majors" />, { preloadedState }); ... }); });

Spying

Also, another concept is ‘spying’ on a function. Rather than mocking, we want to have the full implementation but instead we still want a way to see if that function has been called. Spying is particularly useful for any reducer dispatches. To enable spying on the reducer dispatches, we use our own custom useDispatch and useSelector hooks called useAppDispatch and useAppSelector. To see a good example on spying, refer to frontend/src/pages/DegreeWizard/ResetModal/ResetModal.test.tsx.

Integration Testing

TBD