Je considère que je envisage de réactiver mon blog (actuellement en PHP, mais <100 lignes de code non présentant un code) dans Ruby sur rails juste pour le plaisir de cela. Je veux faire un autre projet dans les rails, mais je devrais apprendre des rails (plus que Hello World) avant d'essayer de créer un projet complet.
Une autre chose que je veux faire tout en refaitant mon blog est de comprendre au moins ce que TDD est tout à propos. Alors, comment diriez-vous de prendre une approche axée sur le test de la création d'un blog? Quels tests écrivez-vous? Comment allez-vous commencer?
Chaque fois que je visualise l'écriture d'un blog, vous devez finir par avoir besoin d'un million de tests pour un seul composant pour le tester complètement. Comment puis-je éviter d'écrire trop de tests?
En outre, je fais ce wiki communautaire parce que j'ai l'intention de cela d'être fondamentalement transformé en un mini-tutoriel / base de connaissances ...
Je suis allé de l'avant et j'ai mis une prime sur cette question alors peut-être que je peux réellement avoir une bonne réponse à cela.
5 Réponses :
TDD est plus sur la conception, puis il est sur le test. Beaucoup de gens manquent cela et finira pratiquer quelque chose qui ne se sent pas tout à fait comme TDD. Avec TDD, vous écrivez un test pour conduire un changement dans votre code. Vous ne devriez pas avoir à vous soucier d'écrire trop de tests, parce que vous ne devriez avoir un test pour écrire s'il y a plus de code de production à écrire (et, par conséquent, plus de code à tester). Encore une fois, TDD agit pas seulement d'écrire beaucoup de tests pour votre code, mais vous finirez avec beaucoup de tests et, par conséquent, vous aurez une suite très puissante de tests pour vous donner des commentaires que votre code évolue et grandit.
Plutôt que de parler de la façon de tester le développement d'un certain morceau particulier de logiciel, je vous recommande de lire et d'apprendre comment pratiquer TDD et comprendre, comme vous le dites, ce que son tout. Un bon livre à considérer est: croissant Orienté Objet Logiciel, guidée par des tests . Le livre utilise Java, mais il est une grande application réelle de l'utilisation de TDD pour construire une pièce assez complexe de logiciels.
Il y a beaucoup à TDD, et je recommande vraiment creuser pour quelques bonnes sources si vous voulez apprendre et essayer de mettre en pratique parce qu'il ya plus que ce qui peut être élevé dans des réponses à cette question.
Commencez par écrire des caractéristiques de concombre pour fournir une couverture «extérieure». Ceux-ci devraient être capables de tester la grande majorité de vos fonctionnalités par elles-mêmes. Très facile à écrire. Un blog n'a pas de nombreux tests, après tous, il s'agit de postes et de commentaires, non? Regardez mon Application Blorgh qui est une application Rails développée à l'aide de concombre.
intéressant, c'est exactement ce que j'ai commencé il y a quelques jours. J'utilise RSPEC et Concombre . J'ai commencé par écrire quelques spécifications pour Cela fonctionne vraiment bien pour moi, mais je suppose que commencer par le concombre est bon aussi autant que beaucoup semblent aimer cette approche.
Si vous n'avez que peu de connaissances sur RSPEC et CUCOMBER, je recommande vivement Railscasts :
J'ai aussi aimé le PEEPCODE ScreenCasts mais contrairement aux rails, ils coûtent 9 $ chacun. article et commentaire modèles. Quand ils sont tous allés au vert, j'ai écrit des tests de concombre pour mettre en œuvre des vues, des contrôleurs, etc.
Regardez les parties prenantes et ce qu'ils veulent accomplir. Il est important de commencer là, car cela vous permet de prioriser correctement (c'est-à-dire pas sur la partie technique la plus intéressante, mais de la part de la plus grande valeur commerciale). Le développeur est un intervenant et réduisant ses peurs (de ne pas pouvoir construire quelque chose) est un objectif valide.
La pensée de la conception est écrite dans les tests. Commencez avec les parties prenantes finales, travaillez de là à l'envers jusqu'au début (heure d'inversion). Cela garantit que vous vous concentrez sur quoi, et moins sur la façon dont. L'interaction entre les objets est plus importante pour obtenir la droite que les attributs d'objet.
Voir:
J'ai une opinion similaire à Pete, c'est plus sur le design.
sauter dessus avant d'avoir examiné des informations de qualité n'est probablement pas de vous donner les résultats. Il suffit probablement de vous faire penser: ces tests se sentent comme une douleur. C'est une prise de conscience qu'il existe des problèmes de conception, mais Vous avez dit "Actuellement en PHP, mais <100 lignes de code non présenté", si c'est le cas, il y a probablement une poignée de fonctionnalités. Si vous vous concentrez sur les fonctionnalités réelles nécessaires, il devrait également y avoir peu de tests / plus élevés que la quantité de fonctionnalités bien sûr, mais aussi longtemps que celles-ci sont les tests d'unité appropriés, le nombre ne doit pas exploser -
Pourquoi essayez-vous d'éviter d'écrire trop de tests? J'avais plus de 100 tests unitaires avec TDD pour une seule classe avec des algorithmes récursifs. Il n'a jamais eu d'insecte lorsque l'application a été libérée et que personne ne s'est jamais plainte qu'elle avait tant de tests.
@c_ma parce que je veux finir par finir mon blog :)
Vous ne pouvez pas limiter artificiellement le nombre de tests lorsqu'ils conduisent votre développement. Dire que vous voulez éviter d'écrire trop de tests dans ce cas, c'est comme un peintre disant qu'il veut éviter d'ouvrir ce tube supplémentaire de peinture.
@C_M Combien de tests écrivez-vous pour une fonctionnalité alors? Si j'étaise BBCode, combien de tests devrais-je faire? 1 Pour tester toutes les fonctionnalités? 1 test par caractéristique? Qu'en est-il des combinaisons de fonctionnalités telles que
[b] [i] [i] [url] ? Où arrêtez-vous de tout tester?