Why Unit Testing Matters?
In the spirit of Technological utopianism, software products would not have any bugs. Until then, developers should test the code as best as they can.
Looking at the four quadrants of agile testing, the unit testing is part of the 1st quadrant– the very first line of defense for code quality. It’s also commonly known that both unit and manual testing by the developer uncover around 66% of the errors before hitting the next testing quadrant. The earlier bugs are found by the developers, the “cheaper” they are. Once bugs hit the next development stages, more people and processes need to get involved for identifying and fixing bugs, which can result in the loss of trust in an application.
When Lightning web component has the unit test, the focus needs to be done on testing the functionality of one’s own component. Any functionality of one’s child components should not be tested. Whatever one expects their child components to do, that’s an implementation detail of each child component itself. It should be covered within that specific child component tests.
Salesforce has added a lot of tests to Lightning web component recipes’ sample application. Let us look at a list of best practices, recommendations, and rules that need to be checked out for making the best out of when crafting tests.
- Different test cases shouldn’t be mixed into one single test. The focus should be on writing a test for a piece of functionality. Tests for Lightning web component can be short or long. Be sure of testing what’s needed.
- Description of desired accomplishment for the test not only gives a better focus when writing it but also lets others directly see what the test is about.
- It should be tested that a component is displaying the expected outcome. Bundling tests and focus on data and UI representation in test suites help a lot with the organization.
Data (Apex and @wire)
- For testing imperative Apex calls, one has to mock the calls. Provisioning data and errors functionality are provided by Jest.
- Test data for one’s @wire tests relative should be put to the test file. Also mocks should be ready for simulating that no data is returned.
- For successful @wire call testing, you emit data otherwise you error them.
- For testing, if @wire adapter receives the correct parameters, getLastConfig() should be used.
- Mocks should be cleared or else at times, testing them will fail.
- When one tests if UI elements are filled based on mocked test data, mocked test data should be used within the tests for improving consistency.
- Every base Lightning component needs to be mocked. Salesforce provides a default mock automatically. In this way, one can test function execution and properties.
- One can create their own implementation when they want to test behavior, not covered by base Lightning components. One can make it available globally to their application using the jest.config.js file. It is also applicable to components that are not from the namespace, like from managed packages.
- If one executes code within the lifecycle methods, they use document.body.appendChild() and document.body.removeChild() for executing them.
- While loading static resources, one can either simply test the UI behavior in case of a successful or unsuccessful load without using the resource. By overriding the default mock implementation, one really loads the static resource.
- Public properties on the first render should be tested by setting them before the addition of the main element in the document to ensure correct initialization.
- If one tests JSON objects, toEqual matcher should be used.
- When one has to use timers in their Lightning web component, they should make sure to set the test up for that, and for running them before validating the UI.
- One might have to add CSS classes or a data-* attribute to an LWC markup for obtaining the desired element to be tested.
- Depending on what one wants to test, one should remember that a promise can chain more than one then().
- One can override global APIs like fetch with their own mocks.
Chief Technical Officer (CTO)