Cet article mérite votre attention si vous Vous êtes passionné par l’écriture de logiciels de bonne qualité et souhaitez améliorer la stabilité de votre application avec des tests. Vous en avez assez des bugs inattendus qui apparaissent dans vos systèmes de production. Besoin d'aide pour comprendre ce que sont les tests automatisés et comment les aborder. Pourquoi avons-nous besoin de tests automatisés ? En tant qu'ingénieurs, nous voulons , mais à chaque nouvelle fonctionnalité que nous créons, nous augmentons inévitablement la taille et la complexité de nos applications. créer des choses qui fonctionnent À mesure que le produit se développe, il devient de plus en plus long de tester (par exemple avec vos mains) chaque fonctionnalité affectée par vos modifications. manuellement L'absence de tests automatisés nous amène soit à passer trop de temps et à ralentir notre vitesse d'expédition, soit à dépenser trop peu pour économiser la vitesse, ce qui entraîne de nouveaux bugs dans le backlog ainsi que les appels de fin de soirée de PagerDuty. Au contraire, . Alors les ordinateurs peuvent être programmés pour faire la même chose à plusieurs reprises déléguons les tests aux ordinateurs ! Types de tests L' suggère . Examinons en profondeur chaque type et comprenons pourquoi nous avons besoin de chacun. idée de la pyramide des tests trois types principaux de tests : unitaires, d'intégration et de bout en bout Tests unitaires Une est un petit élément logique que vous testez de manière (sans compter sur d'autres composants). unité isolée Ils terminent en quelques secondes. leur permet de les exécuter à tout moment, localement et sur CI, sans lancer les services dépendants/effectuer des appels d'API et de base de données. Les tests unitaires sont rapides. L'isolation une fonction qui accepte deux nombres et les additionne. Nous voulons l'appeler avec différents arguments et affirmer que la valeur renvoyée est correcte. Exemple de test unitaire : // Function "sum" is the unit const sum = (x, y) => x + y test('sums numbers', () => { // Call the function, record the result const result = sum(1, 2); // Assert the result expect(result).toBe(3) }) test('sums numbers', () => { // Call the function, record the result const result = sum(5, 10); // Assert the result expect(result).toBe(15) }) Un exemple plus intéressant est le composant React qui restitue du texte une fois la requête API terminée. Nous devons nous moquer du module API pour renvoyer les valeurs nécessaires à nos tests, restituer le composant et affirmer que le code HTML rendu contient le contenu dont nous avons besoin. // "MyComponent" is the unit const MyComponent = () => { const { isLoading } = apiModule.useSomeApiCall(); return isLoading ? <div>Loading...</div> : <div>Hello world</div> } test('renders loading spinner when loading', () => { // Mocking the API module, so that it returns the value we need jest.mock(apiModule).mockReturnValue(() => ({ useSomeApiCall: jest.fn(() => ({ // Return "isLoading: false" for this test case isLoading: false })) })) // Execute the unit (render the component) const result = render(<MyComponent />) // Assert the result result.findByText('Loading...').toBeInTheDocument() }) test('renders text content when not loading', () => { // Mocking the API module jest.mock(apiModule).mockReturnValue(() => ({ useSomeApiCall: jest.fn(() => ({ // Return "isLoading: false" for this test case isLoading: false })) })) // Execute the unit (render the component) const result = render(<MyComponent />) // Assert the result result.findByText('Hello world').toBeInTheDocument() }) Tests d'intégration Lorsque votre interagit avec d’autres , nous appelons cela une . Ces tests sont plus lents que les tests unitaires, mais ils testent la manière dont les parties de votre application se connectent. unité unités (dépendances) intégration Un service qui crée des utilisateurs dans une base de données. Cela nécessite qu'une instance de base de données ( ) soit disponible lors de l'exécution des tests. Nous testerons que le service peut créer et récupérer un utilisateur depuis la base de données. Exemple de test d'intégration : dépendance import db from 'db' // We will be testing "createUser" and "getUser" const createUser = name => db.createUser(name) // creates a user const getUser = name => db.getUserOrNull(name) // retrieves a user or null test("creates and retrieves users", () => { // Try to get a user that doesn't exist, assert Null is returned const nonExistingUser = getUser("i don't exist") expect(nonExistingUser).toBe(null); // Create a user const userName = "test-user" createUser(userName); // Get the user that was just created, assert it's not Null const user = getUser(userName); expect(user).to.not.be(null) }) Tests de bout en bout Il s'agit d'un test lorsque nous testons l' , où toutes ses dépendances sont disponibles. Ces tests simulent au mieux le comportement réel de l'utilisateur et vous permettent de détecter dans votre application, mais il s'agit du type de test . de bout en bout application entièrement déployée tous les problèmes possibles le plus lent Chaque fois que vous souhaitez exécuter des tests de bout en bout, vous devez provisionner toute l'infrastructure et vous assurer que des fournisseurs tiers sont disponibles dans votre environnement. Vous souhaitez les disposer pour les fonctionnalités de votre application. uniquement critiques flux de connexion. Nous voulons accéder à l'application, remplir les informations de connexion, la soumettre et voir le message de bienvenue. Jetons un coup d'œil à un exemple de test de bout en bout : test('user can log in', () => { // Visit the login page page.goto('https://example.com/login'); // Fill in the login form page.fill('#username', 'john'); page.fill('#password', 'some-password'); // Click the login button page.click('#login-button'); // Assert the welcome message is visible page.assertTextVisible('Welcome, John!') }) Comment choisir le type de test à rédiger ? N'oubliez pas que et . les tests de bout en bout sont plus lents que l'intégration que les tests d'intégration sont plus lents que les tests unitaires Si la fonctionnalité sur laquelle vous travaillez est critique, envisagez d'écrire au moins un test (par exemple, vérifier le fonctionnement de la fonctionnalité de connexion lors du développement du flux d'authentification). de bout en bout Outre les flux critiques, nous souhaitons tester autant de cas extrêmes et différents états de la fonctionnalité que possible. nous permettent de tester comment les parties de l'application fonctionnent ensemble. Les tests d'intégration Les points de terminaison doivent effectuer les opérations, produire le résultat attendu et ne générer aucune erreur inattendue. Avoir des tests d'intégration pour les points finaux et les composants clients est une bonne idée. Les composants clients doivent afficher le contenu correct et répondre aux interactions des utilisateurs avec la façon dont vous attendez qu'ils réagissent. Et enfin, quand faut-il choisir ? Toutes les petites fonctions qui peuvent être testées isolément, telles que qui additionne les nombres, qui restitue la balise , sont d'excellents candidats pour les tests unitaires. Les unités sont parfaites si vous suivez l’approche . les tests unitaires sum Button <button> Test Driven Development Et après? (mais commencez petit) Écrivez des tests ! adapté à votre projet/langage. Chaque langage dispose d'une bibliothèque populaire pour les tests, telle que / pour JavaScript, / pour de bout en bout (utilise également JavaScript), pour Java, etc. Installez un framework de test Jest Vitest Cypress Playwright JUnit Trouvez une petite fonction dans votre projet et écrivez un test pour celle-ci. unitaire Écrivez un test pour une interaction composant/service-base de données. d'intégration Choisissez un scénario critique qui peut être rapidement testé, tel qu'un simple flux de connexion, et écrivez un test pour cela. de bout en bout Faites les choses ci-dessus une fois pour comprendre comment cela fonctionne. Ensuite, recommencez pendant certains travaux sur les fonctionnalités/bugs. Partagez-le ensuite avec vos collègues pour que vous puissiez tous passer des tests, gagner du temps et mieux dormir la nuit ! Ressources utiles : Mon blog personnel de La pyramide des tests pratiques Ham Vocke par Développement piloté par les tests Martin Fowler
