On vous confie un endpoint REST sans aucune documentation. Que testez-vous ?

Commencez par le contrat : codes de statut, schéma de réponse, types de contenu, champs obligatoires et optionnels. Validez ensuite chaque entrée (manquante, mauvais type, hors plage, surdimensionnée), testez l'authentification et l'autorisation y compris l'accès à la ressource d'un autre utilisateur, vérifiez la cohérence des réponses d'erreur, l'idempotence sur les soumissions en double, la pagination et le tri, la limitation de débit, et le comportement quand une dépendance échoue ou expire.

D'abord je cartographie le contrat, parce que sans documentation j'ai besoin de connaître la forme avant de pouvoir la juger. Un appel sur le chemin heureux, puis je regarde le code de statut, les en-têtes, le corps de la réponse, et si les champs sont nommés et typés de façon cohérente. Ensuite j'attaque les entrées une par une : j'omets chaque champ obligatoire, j'envoie une chaîne là où un nombre est attendu, j'envoie un négatif, j'envoie une valeur au-delà de toute longueur raisonnable, j'envoie des champs supplémentaires non demandés pour voir s'il les rejette ou les ignore en silence. Puis la partie qui me tient le plus à cœur, l'autorisation en tant que distincte de l'authentification. Être connecté n'est pas une permission. Je prends donc un jeton valide d'un utilisateur et je demande la ressource d'un autre par son identifiant, parce que cette classe de bug est courante et réellement grave. Après cela : un POST répété crée-t-il deux enregistrements, la pagination se comporte-t-elle à la page zéro et au-delà de la fin, les corps d'erreur ont-ils une forme cohérente, y a-t-il une limitation de débit, et que se passe-t-il quand un service en aval est lent. Je braque un proxy dessus et je trafique les réponses pour voir s'il dégrade ou s'il renvoie une 500.