"Itération Zéro" - test de réception de bout en bout dans la fonction simple de formulaire de contact

Question

Je lisais "Logiciel orienté objet en croissance, guidé par les tests" récemment. Les auteurs de ce livre ont commencé à développer une fonction avec un test d'acceptation de bout en bout (avant le cycle TDD) pour ne pas perdre de vue la progression et s'assurer que vous êtes toujours sur la même page tests unitaires. Ok, donc j'ai commencé à écrire une simple application veeeery en python + django juste pour essayer cette approche. Je veux que l'utilisateur puisse poser une question via le formulaire de contact, la question devrait alors être stockée dans un db, et un signal après l'achèvement devrait être envoyé pour notifier l'expéditeur qui enverra un message de suivi.

Question est - comment vous aborderiez ce premier test de bout en bout dans ce cas? Avez-vous contenir toutes les possibilités dans ce premier test, ou peut-être que je suis mal compris toute cette technique.

Tous les exemples seraient les bienvenus.

Answer 1

Vous n'avez pas du tout à inclure toutes les possibilités dans les tests d'acceptation - vous allez quand même écrire des tests unitaires. Donc, je dirais qu'un simple test «utilisateur peut remplir le formulaire, l'enregistrer et le recharger» est suffisant pour commencer. Vous pouvez ensuite ajouter d'autres tests si vous pensez qu'un aspect particulier de votre système est suffisamment important pour nécessiter des tests d'acceptation. Ne vous inquiétez pas de manipuler toutes les possibilités ici, vous allez encore écrire des tonnes de tests unitaires où vous allez tout tester! Le moyen le plus simple de commencer est de développer votre test d'acceptation en parallèle avec le code: commencez donc par tester que l'utilisateur peut entrer des données, l'implémenter jusqu'à ce qu'il arrête d'échouer, puis ajouter au test la condition que l'utilisateur a Il faudra un certain temps pour implémenter l'infrastructure initiale pour le test d'acceptation, avant même de commencer à écrire le code de production, mais vous ne pouvez pas y échapper et il y a plusieurs avantages à avoir des tests en amont.

Answer 2

Ce cas d'utilisation conduit à plusieurs cas de test (chaque test est un chemin d'exécution possible dédié).

Lorsque vous écrivez des tests, vous vous concentrez sur un résultat possible, après quoi la suite de tests grandit. Les premiers tests vous donnent aussi des filets de sécurité comme tests de régression pour ne rien casser que vous avez déjà implémenté avec succès.

Mes premiers tests seraient:

• chemin Bonne 1ère partie frontend-forme + couche de commande: l'utilisateur transmet des données correctes, le contrôleur prennent la forme et de se connecter à la console/stdout
• chemin Bonne 2ème partie: au lieu de vous connecter à stdout, les choses sont stockés à la base de données
• chemin Bonne 3ème partie: Suivi courrier est envoyé et reçu par l'utilisateur
• erreur de validation de la manipulation (utilisateur remplit incorrectement forment, par exemple, manque champs obligatoires, mauvais Email- modèle)
• ...

Remplissez le reste;) dépend des exigences plus détaillées ...

ci-dessus Souvenez-vous d'aussi simple que possible. Lorsque tous les tests sont en place, refactoriser impitoyablement pour rendre la «qualité interne» agréable.