Guided: Test Case Creation and Execution

In this lab, you'll apply a variety of techniques to create tests for a few different kinds of React components.

To begin, start the application by entering the following into the Terminal:

npm run dev

Then open the following URL in the Web Browser tab (this should be to the right of your Terminal tab):

http://localhost:5173

Make sure to refresh the browser tab after running your server. Alternatively, you can click the following link to open an external browser tab:

{{localhost:5173}}

You will see an application consisting of a simple form.

For each of the following elements, consider the following questions that are instrumental in writing effective tests:

• Question 1: What is the intended use of this component?
• Question 2: How can the user interact with this component? Could they interact in unexpected ways, putting the app in an unforseen state?
• Question 3: Is it possible to quantify or generalize all the possible states that this component could be in?

The components are:

1. A text input where the user must enter their first and last name
2. A radio select where they choose contact preferences
3. A multi select where they choose product preferences.

info> If you get stuck, feel free to consult the completed version of the project located in the solution folder.

The application you have open consists of a variety of different form elements - an input, a radio button, a submit button, and more. Each component, and the application overall, need to have tests applied before the application can be considered reliable.

To begin, you'll focus on two primary steps of successful test implementation:

Deriving Test Cases

Deriving Test Cases is the process of determining what the tests will be for each component, based on your knowledge of

1. How the user will interact with the components
2. What the overall purpose of the application is
3. What the individual specifications of the component are

When deriving test cases, it is more important to consider the user's experience and the overall purpose of the application, than it is to consider the low-level functioning of the componet. Deriving test cases is as much an art as a science, with two different UI Test Engineers possibly coming up with different but equally valid test cases for the same cases. While execution may differ, test cases should cover all mission critical functionality.

Creating Test Cases

Creating Test cases varies based on the technology stack used. Test cases created for physical components, like a new car, are not that different from test cases written for UI components, except the former are executed by people and machines, and the latter are exected virtually.

Your modern application uses React+Vite, so Vitest is a natural choice as the framework for your tests. Vitest is a very modern testing framework based on Jest.

Block-Box testing is a methodology of deriving and writing tests based on the principle that:

the inner workings of the application do not matter, as long as output is correct, given fixed inputs.

This technique lends itself well to UI testing - after all, the user views your application very much like a black box: the input whatever information is required, and expect instant and logical output. It is unlikely that the user ever thinks about how the application is implemented or the processes that are running in the background.

Writing UI tests for elements of the web application using Black Box testing involves the following:

1. Render the application
2. Simulate some event, like a click, that a user would commonly perform
3. Verify that the output (such as a warning message) appears
4. At no point should you check the internal workings of the app.

Equivalence Partitioning and Boundary Value Analysis refer to creating test cases which cover all possible scenarios that the UI might react to.

Consider our name input. There are infinite number of strings the user could input, but we could break them up into the following two equivalence classes:

1. Input that is accepted
2. Input that the form will not except (for example, contains numbers.)

You could also break this infinite space of strings up into the following equivalence classes instead:

1. Input that produces no error message
2. Input that is empty
3. Input that produces a "this may not contain numbers" error message
4. Input that produces a "this must have first and last name" error message

Boundary Value Analysis involves understanding the boundaries which separate valid input from invalid input. These boundaries are a bit less abstract when dealing with numerical values - but it's still possible to find the boundary between some of these equivalence classes:

class a: input that is empty
boundary: any non-numeric character
class b: Input that produces a "this must have first and last name" error message

While testing individual functionality and components provides a low-level view of how well your application is functioning, Snapshot tests provide a high-level overview.

They require very little code to write and update, but will fail if the underlying component changes.

By adding a snapshot test, you'll ensure that other changes elsewhere in the application don't cause unexpected failures in the components you are testing.

Oftentimes, you are not authoring and executing tests for the novelty of seeing your application be tested. Rather, tests often form a crucial part of deployment pipelines where a dedicated and professional crew of QA personnel and testers run an agreed-upon series of tests and sign off on the current build of the application. This is serious work, as contracts may mandate that certain levels of testing be done for all deployments, and not doing so could result in severe penalties.

Test results produced with Vitest can be exported as JSON files instead of plain text output to your terminal. While the plaintext is easy to read, JSON provides professional, archivable and non-ambiguous reporting on which tests run and which passed. For example, a JSON file could be used to prove that your team did not knowingly push a new version of the app which had failing tests.

In the following task, you'll output the results of your test suite to JSON.

In this lab we did the following

• Explored an application scaffolded with Vite, using React as the rendering engine
• Created a test file
• Imported test dependencies from vitest and @testing-library
• Wrote tests using black-box techniques
• Created equivalence partitions and automated tests
• Output test results to JSON

You should feel more confident contributing to existing testing stacks of all kinds, or scaffolding new test suites on existing React applications.

Remember, a web application tester's work is never done - there are always new components to test, new requirements that are created or become apparent, and a shifting ecosystem of containers and package version which require tests to be re-run and re-written. Using the techniques you've learned, you can stay vigilant and contribute to teams as an effective testing engineer.