Dois-je tout tester?

Je vais commencer mon premier vrai projet dans Ruby on Rails , et je me force à écrire des tests TDD . Je ne vois pas de réels avantages à écrire des tests, mais comme cela semble très important, je vais essayer.

Est-il nécessaire de tester toutes les parties de mon application, y compris les pages statiques?

TDD n'est pas une question de test, c'est une question de conception. L'écriture des tests vous oblige à réfléchir au fonctionnement de la classe et au type d'interface dont vous avez besoin. Les tests sont un effet secondaire heureux qui facilite la refonte plus tard.

Donc, dans cet esprit, quel est le comportement d'une page statique et quelle est l'interface?

Ma première réponse serait «aucun» et «aucun».

C'est toujours une analyse coûts-avantages. Quel est le coût de la fonctionnalité pour vous? Si le coût est élevé, testez bien et soigneusement. Si le coût est faible, testez légèrement ou pas du tout.

Il y a aussi le coût du time-to-market à considérer. Il est peut-être préférable pour vous de fournir une fonctionnalité fonctionnant principalement que d'être en retard pour fournir une fonctionnalité entièrement fonctionnelle.

Il est presque impossible de répondre à ces questions dans l'OMI générale.

Je pense qu'il est plus important de préserver la capacité de tester dans le cas où certaines fonctionnalités s'avèrent plus importantes que vous ne l'aviez initialement imaginé.

Je dirais "oui". Si vous avez des tests couvrant même les fonctionnalités et le code les plus simples, vous pouvez être sûr que l'ajout de nouveau code ne fait pas cesser le fonctionnement du code sur place. De même, un test pour chaque bug rencontré empêche les régressions de revenir.

Oui, vous devriez tout tester ...

Vous ne pourrez pas nécessairement écrire des tests automatisés pour tout. Pour vos pages statiques, essayez d'utiliser Selenium http://seleniumhq.org/ pour vous assurer que les choses sont correctes.

D'après mon expérience, certaines choses frontales sont presque impossibles à écrire pour des cas de test, mais c'est pourquoi vous voudriez réellement tester en utilisant le globe oculaire Mark 1.

Les tests sont aussi importants que le codage. Vous devez entendre le dicton "Si quelque chose peut mal tourner, cela arrivera". INMO, Parmi les nombreuses techniques de génie logiciel utilisées pour améliorer la qualité, le test est le plus utile pour vous aider à détecter les problèmes tôt.

Bien que tout tester ne soit pas possible (en particulier avec de petites équipes et de grands systèmes), cela ne signifie pas que vous sautez complètement les tests. Les tests en valent-ils la peine? Voir la section "Recherche précoce des défauts" dans Voir Wiki-SoftwareTesting .

Les tests TDD peuvent également être des spécifications vivantes s'ils sont écrits de cette façon. Les noms des méthodes de test doivent avoir un sens pour un utilisateur professionnel.

Comme d'autres l'ont mentionné, dans les tests Ruby on Rails, il est beaucoup plus important que dans (la plupart) d'autres langues. Cela est dû au manque de compilateur.

Les langages tels que Delphi , C ++, VB.NET , etc ... sont des langages compilés, et votre compilateur détectera de nombreuses erreurs comme les fautes de frappe dans les appels à une méthode. Dans Ruby on Rails, vous saurez uniquement s'il y a une faute de frappe ou une erreur dans votre code si cette ligne de code particulière est exécutée ou si vous utilisez un IDE qui affiche des avertissements visuels.

Comme CHAQUE ligne de code est importante (sinon elle ne serait pas là), vous devez tester chaque méthode que vous écrivez. C'est beaucoup plus simple qu'il n'y paraît si vous suivez certains outils TBDD de base.

J'ai trouvé que les rails de Ryan Bates sur la façon dont je testais étaient inestimables pour moi et ont vraiment mis en évidence la simplicité de TBDD s'il était fait correctement.

Si vous utilisez vraiment la méthodologie TDD, vous n'écrivez pas de code sans avoir d'abord effectué un test unitaire que vous essayez de réussir.

Je dirais de ne pas commencer par TDD. Prenez une décision éclairée lorsque vous avez passé plus de temps à apprendre les stratégies d'architecture en général. TDD ne vous laissera pas sauter ces devoirs bien que vous puissiez commencer à croire que c'est le cas.

Voici mon problème avec ça. Lorsque vous dites que cela semble être beaucoup de temps perdu sur des choses qui ne briseront jamais les TDDers, vous l'apprécierez lorsque cette chose que vous n'aviez pas prévue dans une énorme chaîne de dépendances est brisée. Lorsque vous précisez qu'il est impossible de prédire de telles choses avant d'écrire votre application, ce qui est euh ... pourquoi nous testons, ils vous disent qu'il s'agit vraiment de conception et non de test, même si le test est utile.

Mais les chaînes géantes de dépendances liées imprévisibles ne sont-elles pas le produit d'une conception pourrie?

Alors c'est quoi?

Voici une pensée. N'ayons pas d'énormes chaînes complexes de dépendances en premier lieu en considérant les deux principes suivants de la conception orientée objet de Design Patterns:

"Programmer vers une interface, pas une implémentation"

C'est-à-dire que vos objets ne devraient pas se soucier de qui fait l'appel ou comment ils ont été faits. Seulement que les arguments appropriés ont été introduits et que les méthodes qu'ils appellent à partir d'autres objets sont dirigées pour fonctionner comme prévu. Dans la plupart des cas, votre chaîne de dépendance doit être à un point de liaison, l'appel de méthode de la part de l'appelant et l'endroit où les arguments sont déposés dans vos méthodes. C'est là que vous vous connectez, validez et envoyez des messages utiles pour le débogage lorsque les choses tournent court.

Et:

"Privilégier la composition des objets à l'héritage des classes"

Qui est le mannequin? Le gars qui a fait quelque chose à une classe dans un système d'héritage en cascade alambiqué impliquant environ 30 classes entraînant une rupture des cas marginaux, ou le développeur qui a proposé cette architecture en premier lieu? TDD pourrait vous aider à résoudre les problèmes à l'intérieur de cette tour penchée de la classe Pise plus tôt que vous ne l'auriez pu, mais cela rend-il moins pénible d'essayer de modifier l'un des points finaux de ce code en cas de catastrophe la prochaine fois?

Et c'est là que j'arrive à ce qui me dérange. TDD aide-t-il vraiment à la conception ou permet-il une mauvaise architecture? Il me semble que cela peut être une stratégie auto-réalisatrice. Plus votre équipe n'a pas à assumer la responsabilité d'une architecture médiocre, plus ces composants de test granulaire semblent utiles, mais en fin de compte, votre application devient un PITA de plus en plus grand avec lequel travailler (en supposant qu'ils n'aient jamais beaucoup réfléchi à l'architecture dans le premier endroit). Et le fait de ne pas en reconnaître les conséquences est sans conteste, toujours l'erreur la plus coûteuse que vous pouvez faire lorsque vous travaillez sur une application destinée à être mise à niveau et modifiée au fil du temps.

Pour répondre à la question, pensez à "ce qui pourrait mal tourner ici". En particulier, si vous changez le "code" (balisage / autre), comment aurez-vous l'assurance que vous n'avez pas cassé la page. Eh bien, pour une page statique:

• cela pourrait ne pas rendre
• il pourrait rendre incorrectement
• le JS peut ne pas se charger
• les chemins des images peuvent ne pas fonctionner
• les liens peuvent être rompus

Personnellement, je recommanderais:

• écrire un test sélénium [1] qui vérifie la chaîne attendue sur la page (près du bas si possible). Cela valide le rendu.
• vérifiez qu'il n'y a pas d'erreurs JS (je pense que le sélénium le permet)
• exécuter les pages statiques via un validateur html et, si possible, un vérificateur de liens.
• Je n'ai pas trouvé d'outil pour valider JS, mais vous pourriez trouver du succès avec jslint ou jshint.

Le point à retenir ici est que vous voulez quelque chose qui est répétable, facile à utiliser et qui s'exécutera automatiquement dans votre lanceur de test.

Juste pour ajouter à toutes les réponses déjà excellentes, voici ma réflexion sur ce qu'il faut tester et ce qu'il ne faut pas tester:

Faites un test:

• logique métier
• logique d'application
• fonctionnalité
• comportement,
• donc, tout, vraiment, sauf :

Ne testez pas:

• constantes
• présentation

Il est donc inutile d'avoir un test qui dit:

assert wibble = 3

et un code qui dit

wibble = 3

Et il est également inutile de tester des éléments de présentation, comme si l'icône est en bleu perywinkle, quelle police vous avez utilisée pour les en-têtes, etc.

Donc, vous demandez: "devrais-je tester des pages statiques", et la réponse est: vous les testez dans la mesure où elles font partie de la fonctionnalité, de la logique métier ou du comportement de votre site.

Donc, dans notre application, nous avons un test qui vérifie que les termes et conditions sont disponibles à partir de chaque partie du site - pour les utilisateurs anonymes, pour les utilisateurs connectés, depuis le tableau de bord, à l'intérieur des écrans d'application, etc. Il vérifie simplement qu'il y a un lien appelé "termes et conditions" sur chaque page, que le lien fonctionne, puis le test dit que lorsqu'il arrive sur la page, il "ressemble" aux Ts & C - juste assez pour vous rassurer, c'est la bonne page, sans "tester une constante", ou "tester la présentation" ... afin que vous puissiez vérifier que le texte est correct, par exemple, sans vérifier la taille de police ou la disposition du texte en particulier ...