docs(testing): rewriting the testing documentation

This commit is contained in:
thomas
2023-10-03 20:47:37 +02:00
parent cc896f340e
commit fcf073c8e3
7 changed files with 92 additions and 82 deletions

View File

@@ -5,31 +5,23 @@ sidebar:
order: 108 order: 108
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #17</div> <div class="chip">Challenge #17</div>
## Information ## Information
Testing is a crucial step in building scalable, maintainable, and trustworthy applications. We have a functional application that lists available books for borrowing inside a library. If the book you searched for is available, you will be directed to the corresponding book(s), otherwise, you will end up on an error page.
Testing should never be avoided, even in the face of short deadlines or strong pressure from the product team.
Nowadays, there are numerous awesome tools available that make it easy to test your code and provide a great developer experience.
In this series of testing exercises, we will learn and master [Testing Library](https://testing-library.com/docs/) and [Cypress Component Testing](https://docs.cypress.io/guides/component-testing/angular/overview) that simplifies DOM manipulation for testing any Angular component. The file named `app.component.spec.ts` will let you test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-router-outlet`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
## Statement:
We have a functional application that lists available books for borrowing inside a library. If the book you searched is available, you will be directed to the corresponding book(s), otherwise, you will end up on an error page.
The goal is to test this behavior with Testing library and Cypress
The file named `app.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-router-outlet`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
For testing cypress, you will execute your test inside the `app.component.cy.ts` and run `npx nx component-test testing-router-outlet` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode. For testing cypress, you will execute your test inside the `app.component.cy.ts` and run `npx nx component-test testing-router-outlet` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
I created some `it` blocks but feel free to add more test if you like to. # Statement
The goal is to test multiple behaviors of the application described in each test file using Testing library and Cypress Component Testing.
:::note
I have created some `it` blocks but feel free to add more tests if you want.
:::
--- ---

View File

@@ -5,25 +5,27 @@ sidebar:
order: 109 order: 109
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #18</div> <div class="chip">Challenge #18</div>
## Statement: ## Information
We have a small application that sends a title, typed into an input to a fake backend.
If the title is correctly typed, you can send the request otherwise you receive an error and the request is not sent.
The application is created with <b>nested components</b>. `ChildComponent` is the container that includes four components: `ResultComponent`, `ButtonComponent`, `InputComponent` and `ErrorComponent`. However since we are testing our component as a black box, the architecture of our components doesn't change anything. You can create your test, change how the components are structured, and your tests should still pass. That's the goal of integration tests. <b>Never test internal implementation details!!!</b>.
We have a small application that send a title to a fake backend that you type inside a input.
If the title is correctly typed, you can send the request otherwise you get a nice error and the request is not sent.
You can play with it by running : `npx nx serve testing-nested`. You can play with it by running : `npx nx serve testing-nested`.
The goal is to test this behavior with Testing library and Cypress
The file named `child.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-nested`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks. The file named `child.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-nested`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
For testing cypress, you will execute your test inside the `child.component.cy.ts` and run `npx nx component-test testing-nested` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode. For testing cypress, you will execute your test inside the `child.component.cy.ts` and run `npx nx component-test testing-nested` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
I created some `it` blocks but feel free to add more test if you like to. # Statement
The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
:::note
I have created some `it` blocks but feel free to add more tests if you want.
:::
--- ---

View File

@@ -5,24 +5,25 @@ sidebar:
order: 110 order: 110
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #19</div> <div class="chip">Challenge #19</div>
## Statement: ## Information:
We have a small counter application that increments or decrements a number. The `CounterComponent` takes an initial value as an `@Input` and emits the result of the counter as an `@Output` when we click on the **Send** button. Since we are testing our component as a black box, we only have access to our inputs and listen to the output values. <b>We should not rely on any internal implementation details!!!</b>
We have a small counter application that increment or decrement a number.
You can play with it by running : `npx nx serve testing-input-output`. You can play with it by running : `npx nx serve testing-input-output`.
The goal is to test `CounterComponent` with Testing library and Cypress The file named `counter.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-input-output`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
The file named `counter.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-nested`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks. For testing cypress, you will execute your test inside the `child.component.cy.ts` and run `npx nx component-test testing-input-output` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
For testing cypress, you will execute your test inside the `counter.component.cy.ts` and run `npx nx component-test testing-nested` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode. # Statement
I created some `it` blocks but feel free to add more test if you like to. The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
:::note
I have created some `it` blocks but feel free to add more tests if you want.
:::
--- ---

View File

@@ -5,27 +5,29 @@ sidebar:
order: 111 order: 111
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #20</div> <div class="chip">Challenge #20</div>
## Statement: ## Information:
The goal of this challenge is to test dialogs inside your application. In this small application, you have an input prompting you to enter a name, and a **Confirm** button to submit your form.
Within this program, you will get an error modal if the user doesn't input a name, while a confirmation modal will appear in all other cases. If you enter a name, a confirmation modal will appear; otherwise an error modal will be displayed.
In the confirmation modal, if you click the "confirm" button, a message confirming the submission of the form will appear. Otherwise, if the user clicks on "Cancel", an error message will be displayed. In the confirmation modal, if you click the **Confirm** button, a message confirming the submission of the form will appear. If the user clicks on **Cancel**, an error message will be displayed.
The goal of this challenge is to test the dialogs inside your application. To do so, we will test the full application like an end-to-end test will do. This means, we will test the `AppComponent` as a black box and react to events on the page. <b>No internal details should be tested</b>. The difference between an e2e test and integration test is that we will mock all API calls. _(All http requests are faked inside this application, but this would not be the case in a real entreprice application.)_
You can play with it by running : `npx nx serve testing-modal`. You can play with it by running : `npx nx serve testing-modal`.
The goal is to test this behavior with Testing library and Cypress
The file named `app.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-modal`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks. The file named `app.component.spec.ts` will let test your application using Testing Library. To run the test suits, you need to run `npx nx test testing-modal`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
For testing cypress, you will execute your test inside the `app.component.cy.ts` and run `npx nx component-test testing-modal` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode. For testing cypress, you will execute your test inside the `app.component.cy.ts` and run `npx nx component-test testing-modal` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
I created some `it` blocks but feel free to add more test if you like to. # Statement
The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
:::note
I have created some `it` blocks but feel free to add more tests if you want.
:::
--- ---

View File

@@ -5,23 +5,23 @@ sidebar:
order: 10 order: 10
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #28</div> <div class="chip">Challenge #28</div>
## Information ## Information
This is the perfect example to get started with `Testing Library`. This application is very simple. It consists of a checkbox that enables or disables a button. The primary goal of this application is to become familiar with the debug API of Testing Library. Knowing how to debug your tests is a crucial tool you need to have in your toolkit.
You will need to only check if the button gets enabled when clicking on the checkbox You can find the documentation about debugging in Testing Library [here](https://testing-library.com/docs/dom-testing-library/api-debugging#screenlogtestingplaygroundurl).
You can look into debug function to get full power of `Testing Library` like: The main functions to remember are as follows:
- logRoles(...); - `logRoles(myDOMElement)`: prints out all ARIA roles within the tree of the given DOM element. ARIA roles are the primary selectors you should reach for in the first place.
- screen.debug(); // you can pass a element as input - `screen.debug()` or `screen.debug(myDOMElement)`: prints the DOM inside the console.
- screen.logTestingPlaygroundURL(); // you can pass a element as input - `screen.logTestingPlaygroundURL()` or `screen.logTestingPlaygroundURL(myDOMElement)`: this function is very powerful. It will create a playground to expose all elements, and you can interact with it to see the selectors you should choose for a DOM element.
## Statement
The goal of this challenge is not to submit an answer, but you can if you want. It's more about using the debugging API to play around. These tools will be of great help for the upcoming testing challenges.
--- ---

View File

@@ -5,22 +5,31 @@ sidebar:
order: 205 order: 205
--- ---
:::note
WIP: The following documentation will be reviewed and improved. However, you can still take on the challenge. If you don't understand a certain part, please feel free to reach out or create an issue.
:::
<div class="chip">Challenge #29</div> <div class="chip">Challenge #29</div>
## Statement: ## Information:
I built this more real life application to create more real life test cases. This application presents a greater challenge because it closely resembles a real-life application that you might encounter in your day-to-day activities as an Angular developer. What makes it more difficult is the need to handle asynchronous tasks and create appropriate mocks.
In this application, you can search for tickets, you can assign or finish them. You can also create new tickets.
This is a very simple application, but it will let you deal with asynchronous task and mocks The application is a typical todo list application. You can filter tickets, create new ones, assign each ticket, close others, and navigate to the details of each ticket.
The goal of this challenge is to write all test cases of `ticket.store` , `list.component` and `row.component` with Testing Library. In this challenge, you will write tests for the `ListComponent`, which represents the global view, and the `RowComponent`, which represents a specific ticket. Additionally, you will need to write unit tests for the `TicketStoreService` using Testing Library. _This library allows you to test services effectively._
You can also do it with cypress. Handling asynchronous tasks will be particularly challenging. It's important not to introduce any explicit <b>waits</b> in your tests, as this would introduce unnecessary delays. Instead, it's better to look for an element that needs to appear or disappear from the DOM. In this case, the test will naturally wait for the correct period of time, as the waits are already implemented within both libraries. Take advantage of these built-in functionalities to create efficient and reliable tests.
You can play with it by running : `npx nx serve testing-todos-list`.
To run Testing Library test suits, you need to run `npx nx test testing-input-output`. You can also install [Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner) to execute your test by clicking on the `Run` button above each `describe` or `it` blocks.
For testing cypress, you will execute your test inside the `child.component.cy.ts` and run `npx nx component-test testing-input-output` to execute your test suits. You can add the `--watch` flag to execute your test in watch mode.
# Statement
The goal is to test multiple behaviors of the application describe inside each test files using Testing library and Cypress Component Testing.
:::note
I have created some `it` blocks but feel free to add more tests if you want.
:::
--- ---

View File

@@ -9,14 +9,30 @@ sidebar:
import { LinkCard } from '@astrojs/starlight/components'; import { LinkCard } from '@astrojs/starlight/components';
In this series of challenges about testing, you will learn how to write <b>Integration tests</b> using [Testing Library](https://testing-library.com/) and [Cypress Component Testing](https://docs.cypress.io/guides/component-testing/overview). Testing is a crucial step in building scalable, maintainable, and trustworthy applications.
Testing should never be avoided, even in the face of short deadlines or strong pressure from the product team.
Nowadays, there are numerous awesome tools available that make it easy to test your code and provide a great developer experience.
The benefits of using Testing Library or Cypress Component Testing are to test your component as a black box. You will only interact with what the user can do on the UI. However, the difference with end-to-end tests is that the backend is mocked, which makes the tests faster and more maintainable. In this series of testing exercises, we will learn and master [Testing Library](https://testing-library.com/docs/) and [Cypress Component Testing](https://docs.cypress.io/guides/component-testing/angular/overview) that simplifies DOM manipulation for testing any Angular component.
The benefits of using <b>Testing Library</b> or <b>Cypress Component Testing</b> are to test your component as a black box. You will only interact with what the user can do on the UI. However, the difference with end-to-end tests is that the backend is mocked, which makes the tests faster and more maintainable.
The goal is to mock as little as possible to test your component at a higher level than unit testing, which will make refactoring easier. The goal is to mock as little as possible to test your component at a higher level than unit testing, which will make refactoring easier.
Within a real application, integration tests are the tests you will write the most. Learning how to write them will make your application more robust and more maintainable. Within a real application, integration tests are the tests you will write the most. Learning how to write them will make your application more robust and more maintainable.
Here is a series of 8 challenges that you can take in any order. Here is a series of 8 challenges that you can take in any order.
<LinkCard
title="🟢 Harness"
description="Learn how to test using Angular CDK Component harnesses"
href="/challenges/testing/23-harness/"
/>
<LinkCard
title="🟢 Checkbox"
description="Learn how to debug your tests using Testing Library on a simple checkbox application"
href="/challenges/testing/28-checkbox/"
/>
<LinkCard <LinkCard
title="🟠 Router" title="🟠 Router"
description="Learn how to test the routed components" description="Learn how to test the routed components"
@@ -41,24 +57,12 @@ Here is a series of 8 challenges that you can take in any order.
href="/challenges/testing/20-modal/" href="/challenges/testing/20-modal/"
/> />
<LinkCard
title="🟢 Harness"
description="Learn how to test using Angular CDK Component harnesses"
href="/challenges/testing/23-harness/"
/>
<LinkCard <LinkCard
title="🟠 Harness Creation" title="🟠 Harness Creation"
description="Learn how to create harness on your own components" description="Learn how to create harness on your own components"
href="/challenges/testing/24-harness-creation/" href="/challenges/testing/24-harness-creation/"
/> />
<LinkCard
title="🟢 Checkbox"
description="Learn how to test a basic checkbox"
href="/challenges/testing/28-checkbox/"
/>
<LinkCard <LinkCard
title="🔴 Real-life Application" title="🔴 Real-life Application"
description="Learn how to write a series of test for a real-life applications" description="Learn how to write a series of test for a real-life applications"