mirror of
https://github.com/MaximePIERRONT/but3-cours-maitenance-applicative.git
synced 2024-12-27 04:12:19 +01:00
🎉
This commit is contained in:
parent
5d76da6b0e
commit
685d89af75
@ -1 +1,7 @@
|
||||
# but3-cours-maitenance-applicative
|
||||
# but3-cours-maitenance-applicative
|
||||
|
||||
## Cours 1 : Introduction à la maintenance applicative et Test Driven Development
|
||||
|
||||
## Cours 2 : Behvaior Driven Development
|
||||
|
||||
## Cours 3 : Les tests End-to-End
|
551
cours1-bonne-pratique-tdd/cours1.md
Normal file
551
cours1-bonne-pratique-tdd/cours1.md
Normal file
File diff suppressed because it is too large
Load Diff
180
cours2-bdd/cours2.md
Normal file
180
cours2-bdd/cours2.md
Normal file
@ -0,0 +1,180 @@
|
||||
---
|
||||
marp: true
|
||||
paginate: true
|
||||
---
|
||||
|
||||
# R6.06. Maintenance applicative
|
||||
## Cours 2
|
||||
|
||||
---
|
||||
|
||||
# Présentation
|
||||
|
||||
## Maxime Pierront - [contact@pierrontmaxi.me](mailto:contact@pierrontmaxi.me)
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Behavior Driven Development (BDD)
|
||||
Le **BDD** est une approche de développement logiciel qui se concentre sur la collaboration entre les membres de l'équipe pour comprendre et définir le comportement attendu du logiciel.
|
||||
|
||||
Le **BDD** se base sur les principes du **TDD** (Test Driven Development), mais avec une approche plus orientée vers la communication et la collaboration entre les différents intervenants (développeurs, testeurs, chefs de projet, utilisateurs finaux, etc.).
|
||||
|
||||
---
|
||||
|
||||
# Le processus de BDD se déroule en trois étapes :
|
||||
|
||||
1. Définir les comportements attendus du logiciel sous forme de scénarios concrets et compréhensibles par tous les intervenants.
|
||||
2. Écrire des tests automatisés qui vérifient que les comportements définis dans les scénarios sont correctement implémentés dans le code.
|
||||
3. Implémenter le code qui répond aux comportements attendus et passer les tests avec succès.
|
||||
|
||||
Le BDD encourage la communication et la collaboration entre les différents membres de l'équipe pour s'assurer que le logiciel répond aux besoins réels des utilisateurs finaux. Il permet également de réduire les risques d'erreurs et de malentendus en clarifiant les exigences et en les traduisant en scénarios concrets.
|
||||
|
||||
---
|
||||
|
||||
# Libraire pour faire du BDD
|
||||
## Cucumber
|
||||
Cucumber est un outil open source utilisé pour faire du Behavior Driven Development (BDD). Il permet de décrire les comportements attendus d'une application sous forme de scénarios écrits en langage naturel, accessibles à tous les membres de l'équipe (développeurs, testeurs, chefs de projet, utilisateurs finaux, etc.).
|
||||
|
||||
---
|
||||
|
||||
# Cucumber
|
||||
Les scénarios Cucumber sont écrits dans un format appelé Gherkin, qui utilise une syntaxe simple et lisible pour décrire les étapes d'un scénario. Chaque scénario est composé de trois parties :
|
||||
|
||||
**Given** : décrit l'état initial du système avant que l'utilisateur n'effectue une action.
|
||||
**When** : décrit l'action effectuée par l'utilisateur.
|
||||
**Then** : décrit le résultat attendu après l'action de l'utilisateur.
|
||||
|
||||
---
|
||||
|
||||
# Exemple fichier feature
|
||||
|
||||
```feature
|
||||
Feature: FizzBuzz
|
||||
|
||||
En tant qu'utilisateur,
|
||||
Je veux pouvoir générer une liste d'entiers de 1 à 100
|
||||
Avec les règles suivantes :
|
||||
- Pour les multiples de 3, remplacez le nombre par "Fizz"
|
||||
- Pour les multiples de 5, remplacez le nombre par "Buzz"
|
||||
- Pour les multiples de 15, remplacez le nombre par "FizzBuzz"
|
||||
|
||||
Scenario: Générer la liste FizzBuzz
|
||||
Given que je génère la liste d'entiers de 1 à 100
|
||||
When j'applique les règles FizzBuzz
|
||||
Then je devrais obtenir la liste suivante :
|
||||
| 1 | 2 | Fizz | 4 | Buzz | Fizz | 7 | 8 | Fizz | Buzz | 11 | Fizz | 13 | 14 | FizzBuzz | ... |
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Ajouter cucumber sur le projet
|
||||
|
||||
Ajout de cucumber : `npm install --save-dev @cucumber/cucumber`
|
||||
Ajout d'un nouveau script dans `package.json` :
|
||||
```js
|
||||
"scripts": {
|
||||
"test": "jest",
|
||||
"behavior": "npx cucumber-js"
|
||||
}
|
||||
```
|
||||
Création du fichier à la racine `cucumber.js` avec le contenu suivant :
|
||||
```js
|
||||
module.exports = {
|
||||
default: {
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Ajout fichier feature
|
||||
Création dossier `features` à la racine
|
||||
Création dossier support : `features/support`
|
||||
Dans `features` créer le fichier `sum.feature` suivant :
|
||||
```feature
|
||||
Feature: Sum two numbers
|
||||
|
||||
Scenario: Add two numbers
|
||||
Given I have a sum function
|
||||
When I add 1 and 2
|
||||
Then the result should be 3
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Ajout de la glue
|
||||
|
||||
Dans `support` créer le fichier `sum-steps.js` suivant :
|
||||
```js
|
||||
const { Given, When, Then } = require('@cucumber/cucumber');
|
||||
const assert = require('assert');
|
||||
const sum = require('../../src/sum');
|
||||
|
||||
let result;
|
||||
|
||||
Given('I have a sum function', function () {
|
||||
// This step is more for context, no action needed
|
||||
});
|
||||
|
||||
When('I add {int} and {int}', function (a, b) {
|
||||
result = sum(a, b);
|
||||
});
|
||||
|
||||
Then('the result should be {int}', function (expectedResult) {
|
||||
assert.strictEqual(result, expectedResult);
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Lancer le test de comportement
|
||||
Commande : `npm behavior`
|
||||
|
||||
---
|
||||
|
||||
# Calculateur de TVA en BDD
|
||||
|
||||
**Consignes :**
|
||||
|
||||
Écrire un programme qui calcule la TVA d'un produit en fonction de son prix hors taxe et du taux de TVA en vigueur.
|
||||
Le programme doit afficher le prix TTC (toutes taxes comprises) du produit.
|
||||
Le taux de TVA peut être modifié par l'utilisateur.
|
||||
|
||||
---
|
||||
|
||||
# Correction calculateur de TVA en BDD
|
||||
|
||||
---
|
||||
|
||||
|
||||
# Le loup, la chèvre et le chou en BDD
|
||||
|
||||
**Consignes :**
|
||||
|
||||
Écrire un programme qui simule le passage du loup, de la chèvre et du chou d'une rive à l'autre d'une rivière à l'aide d'un bateau.
|
||||
* Le bateau ne peut transporter qu'un seul passager à la fois, à l'exception du fermier qui peut le conduire.
|
||||
* Le loup ne peut pas être laissé seul avec la chèvre, sinon il la mangera.
|
||||
* La chèvre ne peut pas être laissée seule avec le chou, sinon elle le mangera.
|
||||
* Le programme doit afficher les étapes nécessaires pour amener les trois passagers sur l'autre rive en toute sécurité.
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Correction le loup, la chèvre et le chou en BDD
|
||||
|
||||
---
|
||||
|
||||
# Recap
|
||||
* Bonne pratique de code
|
||||
* SOLID
|
||||
* KISS
|
||||
* Complexité cyclomatique
|
||||
* TDD
|
||||
* BDD
|
||||
|
||||
---
|
||||
|
||||
## Maxime Pierront - [contact@pierrontmaxi.me](mailto:contact@pierrontmaxi.me)
|
||||
|
119
cours3-e2e/cours3.md
Normal file
119
cours3-e2e/cours3.md
Normal file
@ -0,0 +1,119 @@
|
||||
---
|
||||
marp: true
|
||||
paginate: true
|
||||
---
|
||||
|
||||
# R6.06. Maintenance applicative
|
||||
## Cours 3
|
||||
|
||||
|
||||
### Maxime Pierront - [contact@pierrontmaxi.me](mailto:contact@pierrontmaxi.me)
|
||||
|
||||
---
|
||||
|
||||
# Playwright
|
||||
## Tests End-to-End or E2E
|
||||
|
||||
---
|
||||
|
||||
# Qu'est-ce que les Tests End-to-End (E2E) ?
|
||||
**Définition** : Les tests E2E valident le flux intégral d'une application depuis le début jusqu'à la fin.
|
||||
**Objectif** : Assurer que le flux de travail complet fonctionne comme prévu.
|
||||
**Importance** : Identifier les problèmes d'intégration et les bugs dans des situations réelles.
|
||||
|
||||
---
|
||||
|
||||
# Pourquoi les Tests E2E sont-ils Cruciaux ?
|
||||
* Garantissent la cohérence du comportement de l'application.
|
||||
* Simulent l'expérience utilisateur réelle.
|
||||
* Détectent les problèmes qui pourraient être manqués par les tests unitaires ou d'intégration.
|
||||
|
||||
---
|
||||
|
||||
# Tests E2E vs. Tests Unitaires vs. Tests d'Intégration
|
||||
* Tests Unitaires:
|
||||
* Focus: Fonctionnalités individuelles ou unités de code.
|
||||
* But: Vérifier que chaque partie fonctionne isolément.
|
||||
* Tests d'Intégration:
|
||||
* Focus: Interaction entre différentes unités/modules.
|
||||
* But: Vérifier que les combinaisons de parties fonctionnent ensemble.
|
||||
* Tests E2E:
|
||||
* Focus: Flux d'application complet.
|
||||
* But: Vérifier que le système fonctionne dans son ensemble.
|
||||
|
||||
---
|
||||
|
||||
# Qu'est-ce que Playwright ?
|
||||
Présentation: Un framework de test automatisé open-source pour le web.
|
||||
|
||||
**Avantages** : Prise en charge de plusieurs navigateurs, tests rapides, fonctionne sur tous les OS.
|
||||
**Utilisation** : Idéal pour les tests E2E grâce à sa flexibilité et sa facilité d'utilisation.
|
||||
|
||||
---
|
||||
|
||||
# Playwright Comparé à D'autres Frameworks
|
||||
* Comparaison avec Selenium:
|
||||
* Playwright est souvent plus rapide et plus moderne.
|
||||
* Supporte les dernières fonctionnalités des navigateurs web.
|
||||
* Comparaison avec Cypress:
|
||||
* Playwright supporte les tests multi-navigateurs.
|
||||
* Plus de flexibilité dans les scénarios de test.
|
||||
|
||||
---
|
||||
|
||||
# Comment installer et configurer playwright
|
||||
|
||||
## Installation
|
||||
* Créez un nouveau dossier pour votre projet et naviguez-y `first-steps-playwright`
|
||||
* Exécutez la commande d'installation : `npm init -y`
|
||||
|
||||
---
|
||||
|
||||
# Création du fichier de test
|
||||
* puis `npm init playwright@latest`.
|
||||
* Choisir d'un dossier `e2e` à la racine du projet
|
||||
* **Télécharger les navigateurs de playwright**
|
||||
* Création d'un 2e fichier `test.e2e.spec.js` avec le contenu suivant :
|
||||
```js
|
||||
const { test, expect } = require('@playwright/test');
|
||||
|
||||
test('Test de base sur un site existant', async ({ page }) => {
|
||||
await page.goto('https://example.com');
|
||||
await expect(page).toHaveTitle('Example Domain');
|
||||
});
|
||||
```
|
||||
---
|
||||
|
||||
# Execution des tests
|
||||
|
||||
* Revenez au terminal et lancez le test avec la commande : `npx playwright test`.
|
||||
* *(Optionnel) Ajout d'un raccourcis dans le package.json dans scripts pour lancer les tests plus rapidement*
|
||||
* Playwright va ouvrir le navigateur, exécuter le test, puis le fermer automatiquement.
|
||||
|
||||
---
|
||||
|
||||
# Exemples disponibles
|
||||
## Exemple présente dans ici :
|
||||
`tests-examples/demo-todo-app.spec.js`
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Ajout d'un test End-to-End dans le projet
|
||||
|
||||
---
|
||||
|
||||
# Recap des attendus du projet pour le module maintenance applicative
|
||||
|
||||
* Des tests en **TDD**
|
||||
* Des tests **E2E**
|
||||
|
||||
J'évalurai la qualité des tests de chaque type.
|
||||
|
||||
---
|
||||
|
||||
# Maintenant Projet !!!
|
||||
|
||||
---
|
||||
|
||||
## Maxime Pierront - [contact@pierrontmaxi.me](mailto:contact@pierrontmaxi.me)
|
Loading…
Reference in New Issue
Block a user