La vie d'un service API

• besoins initiaux
• évolutions

Problématique

Comment gérer l'évolution d'une API

Compatibilité ascendante

Si une évolution a lieux

• simple ajout qui respecte le contrat de base
  => R.A.S.
   
• modification du contrat
  => nouvelle version d'API

Le contrat d'API

Une API doit être

• versionnée
• idéalement définie par Swagger
  (ou OpenAPI 3)

Écrire du code

c'est

• découper le code
• factoriser le code commun
• aussi écrire des bugs

Régressions

• Ça marchait ça ne marche plus
• Les clients ne fonctionnent plus

• image de marque
• intervention d'urgence
• perte de temps
• risque de régression

Coûts

Rôles et buts des tests

• Tester la conformité au cahier des charges
• Assurer la reproductibilité
• Vérifier la non régression
• documenter le code

Quoi tester ?

• fonctions publiques
• chemins critiques
• cas limites

Comment tester

• Mock
• Test

 Remarques sur les tests

• ne pas faire que les cas nominaux qui marchent
• faire les tests qui test des erreurs

TDD

Tests Driven Development

Trois pour guider

1. Vous devez écrire un test qui échoue avant de pouvoir écrire le code de production correspondant.
    
2. Vous devez écrire une seule assertion à la fois, qui fait échouer le test ou qui échoue à la compilation.
    
3. Vous devez écrire le minimum de code de production pour que l'assertion du test actuellement en échec soit satisfaite.

Processus itératif du TDD

• écrire un seul test qui décrit une partie du problème à résoudre
   
• vérifier que le test échoue, autrement dit qu'il est valide, c'est-à-dire que le code se rapportant à ce test n'existe pas
   
• écrire juste assez de code pour que le test réussisse
   
• vérifier que le test passe, ainsi que les autres tests existants
   
• puis remanier le code, c'est-à-dire l'améliorer sans en altérer le comportement.

Quelques frameworks

• Jasmine
• Mocha
• Jest
• Tape
• AVA

Jest

• Simple (comme les autres)
• Fait pour tester du react (facebook)
• Fourni un coverage