Share
Êtes-vous nouveau sur Rails? Nouveau pour coder? Vous êtes curieux de connaître RSpec et comment vous pouvez commencer à tester? Si tel est le cas, cet article devrait être un bon point de départ pour vous lancer dans un développement piloté par les tests. Il vous expliquera le pourquoi et le comment et vous donnera un kit de survie pour votre première série de tests..
A quoi sert RSpec? RSpec est très utile au niveau des tests unitaires, car il permet de tester les détails les plus fins et la logique métier de votre application. Cela signifie que vous devez tester les éléments internes, tels que les modèles et les contrôleurs de votre application. Les tests qui couvrent vos vues ou les tests de fonctionnalités qui simulent des flux utilisateur plus complets, tels que l’achat d’un élément, ne seront pas l’objectif de RSpec. RSpec n'utilise pas de pilote Web, comme Capybara par exemple, qui simule les interactions d'un utilisateur avec un site réel ou une représentation de celui-ci..
Le développement piloté par les tests (TDD), à quoi ça sert? Eh bien, ce n’est pas si facile de répondre sans vous nourrir de clichés. J'espère que cela ne semble pas évasif. Je pourrais donner une réponse rapide, mais je veux éviter de vous renvoyer à la maison affamé après avoir seulement pris une petite collation. Le résultat de cette petite série sur RSpec et les tests ne devrait pas seulement vous donner toutes les informations pour répondre vous-même à cette question, mais également vous donner les moyens et la compréhension nécessaires pour commencer à tester tout en vous sentant déjà un peu confiant..
Les débutants semblent avoir plus de difficulté à entrer dans RSpec et le flux de travail TDD que de commencer à devenir dangereux avec Ruby ou Rails. Pourquoi donc? Je ne peux que deviner à ce stade, mais d’une part, la littérature semble principalement axée sur les personnes qui ont déjà quelques compétences en programmation, et d’autre part, apprendre tout ce qui est nécessaire pour bien comprendre un peu intimidant. La courbe d'apprentissage peut être assez raide, je suppose. Pour des tests efficaces, de nombreuses pièces mobiles sont impliquées. C’est beaucoup demander aux débutants qui commencent tout juste à comprendre un cadre tel que Rails d’examiner le processus de création d’une application dans une perspective opposée et d’apprendre une toute nouvelle API pour écrire du code pour votre code.
J'ai réfléchi à la façon d'aborder ce «dilemme» pour la prochaine génération de codeurs qui cherchent juste à commencer plus doucement dans cette affaire. C'est ce que je suis venu avec. Je vais décomposer la syntaxe la plus essentielle pour vous sans supposer bien plus que des connaissances de base de Ruby et un peu de Rails. Au lieu de couvrir tous les angles possibles et de vous dérouter à mort, nous allons passer en revue votre trousse de survie de base et essayer de brosser un tableau plus général. Nous allons discuter du «comment» plutôt verbalement afin de ne pas perdre de nouveaux codeurs en cours de route. La deuxième partie de l’équation expliquera le «Pourquoi?
Si j'ai de la chance, vous aurez une bonne base pour des livres plus avancés tout en ayant confiance en une vue d'ensemble. Ok maintenant, marchons la promenade!
Revenons à l'objectif des tests. Le test est-il utile pour écrire des applications de meilleure qualité? Eh bien, cela peut être chaudement débattu, mais pour le moment je répondrais à cette question par un oui, je suis dans le camp de hipster TDD, je suppose. Voyons pourquoi les tests offrent à vos applications quelques avantages difficiles à ignorer:
Ils vérifient si votre travail fonctionne comme prévu. Il est essentiel de valider constamment que vous écrivez du code qui fonctionne, pour la santé de votre application et la santé mentale de votre équipe..
Ils testent des choses que vous ne voulez pas tester à la main, des vérifications fastidieuses que vous pouvez faire à la main, surtout lorsque vous devez vérifier cela tout le temps. Vous voulez être aussi sûr que possible que votre nouvelle fonction, votre nouvelle classe ou quoi que ce soit ne provoque pas d'effets secondaires dans des zones peut-être totalement imprévues de votre application. L’automatisation de ce genre de choses vous épargne non seulement tonne temps, mais rendra également les scénarios de test cohérents et reproductibles. Cela seul les rend beaucoup plus fiables que les tests manuels sources d'erreurs.
Nous voulons nous assurer que l'application se comporte d'une certaine manière, d'une manière attendue. Les tests permettent de s'assurer, dans une large mesure, du fonctionnement des utilisateurs avec votre application et d'éviter les scénarios de bugs que vous avez pu prévoir. Les tests vérifient que votre application fonctionne comme vous l'avez conçue et qu'elle continue à fonctionner une fois les modifications apportées. Cela est particulièrement important lorsque votre suite de tests vous informe de l'échec des scénarios d'implémentations de votre application qui sont peut-être anciennes et ne sont donc plus tout à fait à l'arrière-plan du cerveau et ne sont pas prises en compte lors de l'introduction de nouvelles fonctionnalités. En bref, cela aide à garder votre application en bonne santé et évite d'introduire des tonnes de bugs.
Les tests automatisés vous font réellement tester plus souvent. Imaginez si vous devez tester quelque chose pour la 40e fois pour une raison quelconque. Si cela prend un peu de temps, sera-t-il facile de s'ennuyer et de sauter le processus? Ces sortes de choses sont la première étape sur une pente glissante où vous pouvez embrasser un pourcentage décent de la couverture de code au revoir.
Les tests fonctionnent comme documentation. Hein? Les spécifications que vous écrivez donnent aux autres membres de vos équipes un point d’entrée rapide pour apprendre une nouvelle base de code et comprendre ce qu’elle est censée faire. L'écriture de votre code dans RSpec, par exemple, est très expressive et forme des blocs de code très lisibles qui racontent une histoire s'ils sont bien faits. Parce qu'il peut être écrit de manière très descriptive tout en étant un langage DSL (Domain Specific Language) très concis, RSpec frappe d'une pierre deux coups: ne pas être bavard dans son API et vous fournir tous les moyens d'écrire des scénarios de test très compréhensibles. C’est ce que j’ai toujours aimé et pourquoi je n’ai jamais eu chaud avec Cucumber, qui résolvait le même problème d’une manière trop conviviale pour les clients, je pense..
Ils peuvent minimiser la quantité de code que vous écrivez. Plutôt que d'essayer des trucs plus freestyle, la pratique de tester votre code vous permet d'écrire uniquement le code nécessaire pour réussir vos tests. Pas de code en trop. Une chose que vous entendrez souvent dans votre future carrière est que le meilleur code est le code que vous n'avez pas à écrire ou quelque chose du genre. Pourquoi? La plupart du temps, les solutions les plus élégantes impliquent des quantités moindres de code. De plus, le code que vous n'écrivez pas (ce qui peut être inutile) ne causera plus de bogues et ne nécessite pas de maintenance. Donc, en écrivant d'abord les tests, avant d'écrire l'implémentation, vous déterminez clairement le problème à résoudre. Écrire uniquement du code nécessaire, et pas plus accidentellement, est peut-être un effet secondaire sous-estimé que TDD peut vous fournir..
Ils ont un effet positif sur votre conception. Pour moi, comprendre cette partie a allumé une ampoule et m'a vraiment fait apprécier tout le processus de test. Lorsque vous écrivez vos implémentations autour de scénarios de test très ciblés, votre code sera probablement beaucoup plus compartimenté et modulaire. Puisque nous sommes tous amis de DRY - «Ne te répète pas!» - et le moins possible de couplage entre les composants de votre application, il s'agit d'une discipline simple mais efficace pour réaliser des systèmes bien conçus. Cet aspect est l'avantage le plus important, je pense. Oui, les autres sont également géniaux, mais lorsque les tests permettent également d'obtenir des applications dont la qualité est meilleure en raison d'un design raffiné, je dirais Jackpot!
Cela revient aussi à l'argent. Lorsque vous disposez d'une application stable, facile à gérer et à modifier, vous économiserez beaucoup d'argent à long terme. Une complexité inutile peut facilement hanter les projets et la motivation ne sera pas à son comble lorsque votre équipe devra combattre votre code, car celui-ci est fragile et mal conçu. Une bonne conception d’application peut absolument soutenir vos objectifs commerciaux, et inversement. Souhaitez-vous introduire de nouvelles fonctionnalités essentielles pour votre entreprise, mais vous combattez constamment votre architecture parce qu'elle a été construite sur du sable? Bien sûr que non, et nous avons tous vu beaucoup d'exemples d'entreprises qui ont rapidement disparu pour cette raison. De bonnes habitudes de test peuvent constituer une ligne de défense efficace dans de telles situations..
Un autre objectif important concerne la qualité de votre code lui-même. Le logiciel que vous écrivez doit être facile à comprendre pour les autres développeurs, autant que possible, au moins. Vos tests peuvent réellement aider à communiquer les fonctionnalités et l’intention de votre application, et pas seulement aux autres membres d’une équipe, mais également à votre avenir. Si vous ne touchez pas à une section de votre code pendant un bon bout de temps, il vous sera très utile de vous rafraîchir la mémoire de la façon dont vous avez écrit un logiciel et de la raison pour laquelle vous avez écrit la documentation fournie par un outil tel que RSpec et RSpec. cela vraiment bien, exceptionnellement en fait.
Puisque votre code changera toujours, le refactoring de votre code fera et devrait toujours faire partie du développement de votre logiciel. Et, étant donné que le changement est tellement intégré dans ce processus, vous devez vous assurer que ces changements ne génèrent pas d'effets secondaires inattendus dans des endroits surprenants. La suite de tests vous offre un filet de sécurité assez serré pour vous sentir plus à l'aise et libre de refactoriser avec brio. Cet aspect, à côté des avantages de conception que TDD peut vous fournir, est mon avantage préféré pour lequel une suite de tests peut vous aider. La modification et l’extension de votre code sont un élément essentiel de l’innovation sur votre «produit» déjà commercialisé, vous avez donc besoin d’un outil qui vous laisse le plus de liberté possible avec ce processus. Je ne suis pas sûr que les personnes qui critiquent la rédaction d'une suite de tests complète se préoccupent beaucoup de cet aspect..
Vous aurez une bonne chance de créer de nouvelles choses plus rapidement dans les étapes ultérieures, car les commentaires de la suite de tests vous donneront des informations sur vos échecs, vos bogues et vos limitations, bien plus rapidement que ne le peut un humain. De plus, cela vous donnera la confiance de travailler avec un filet de sécurité qui devient encore plus précieux au fil du temps.
Dans vos applications, surtout si elles ont connu une croissance significative, vous voulez pouvoir faire confiance à votre logiciel. Une couverture de code à 100% semble beaucoup plus douce quand vous avez un site vieux de quelques années et touché par des centaines de développeurs. Pouvoir faire confiance au nouveau code que vous introduisez et à la construction de celui-ci est l’un des grands plaisirs du développement logiciel que l’argent ne pourra pas acheter plus tard.
rails new your_app -T
-T vous permet de sauter Test Unit, le cadre de test fourni avec Rails.
groupe: développement,: test do gem 'rspec-rails' end
paquet
Après cela, nous devons utiliser un générateur fourni avec RSpec:
les rails génèrent rspec: install
create .rspec create spec create spec / spec_helper.rb create spec / rails_helper.rb
Cela permet de définir la structure de base de vos tests RSpec dans Rails. Comme vous pouvez le voir à la sortie ci-dessus, ce générateur a initialisé un spec répertoire avec quelques fichiers dont vous aurez besoin plus tard. le .rspec Le fichier est un fichier de configuration que nous n’aurons pas besoin de manipuler pour le moment. Je voulais juste vous faire savoir ce que vous avez devant vous. Les autres fichiers s’expliquent d'eux-mêmes, mais je voulais mentionner leurs différences.
Accentsconagua
spec_helper.rb est pour les spécifications qui ne dépendent pas de Rails.rails_helper.rb, d'autre part, est pour les spécifications qui en dépendent.Ce qui n’est pas évident, c’est qu’un de ces fichiers doit être requis en plus de vos fichiers de spécifications (fichiers de test) pour pouvoir exécuter vos tests. Regardons vite! Lorsque vous générez un modèle via:
Les rails génèrent le modèle dummy_model nom: string
invoke active_record create db / migrate / 20160521004127_create_dummy_models.rb create app / models / dummy_model.rb invoke rspec crée spec / models / dummy_model_spec.rb
Non seulement Rails aura-t-il créé le fichier associé? _spec.rb fichiers pour vous, vos spécifications auront également automatiquement nécessite 'rails_helper' par défaut en plus de vos fichiers spec. Cela signifie que vous êtes prêt à partir, tout de suite.
nécessite 'rails_helper'…
Ainsi, avec cette configuration, vous pouvez tester votre application Rails, vos modèles par exemple, et RSpec ne vous tracas pas au sujet des classes de modèles utilisées dans Rails. Cela est nécessaire à chaque fois que vous avez besoin de choses comme ActiveRecord, ApplicationController etc. Donc, ceci est votre scénario normal et devrait donc être votre premier choix logique en tant que débutant.
Requérant spec_helper.rb, En revanche, générera une erreur si vous écrivez des tests qui incluent la logique métier à partir de votre application Rails. Dans ce scénario, RSpec ne sait pas de quoi vous parlez lorsque vous souhaitez tester un modèle Rails, par exemple.
Si longue histoire super courte, spec_helper ne charge pas Rails, c'est tout! Bien sûr, vous pouvez vous déchaîner avec les configurations, mais ce n’est rien que je veuille vous préoccuper pour le moment. Concentrons-nous sur les bases, comment exécuter des tests et la syntaxe. Cela devrait suffire pour commencer. Allons-nous en!
Vous êtes prêt à exécuter vos tests. RSpec nécessite que vos fichiers de test aient un suffixe spécifique comme _spec pour comprendre quels fichiers exécuter. Si vous utilisez un générateur, ce n'est pas un problème, mais si vous voulez écrire des fichiers de test vous-même, voici comment ils doivent se terminer. Donc, vous aurez besoin de mettre un fichier comme your_first_test_spec.rb dans ton spec annuaire.
L’utilisation du générateur pour créer un modèle factice nous a déjà fourni spec / models / dummy_model_spec.rb. Pas mal! Une chose à faire avant que les tests soient prêts:
rake db: migrer rake db: test: prepare
Ces commandes exécutent votre migration pour le modèle factice que nous avons généré ci-dessus et configurent également la base de données de test avec ce modèle. Maintenant, nous effectuons le test:
râteau
le râteau commande exécutera tous vos tests, la suite de tests complète. Habituellement, vous devez utiliser cette commande lorsque vous avez terminé certaines fonctionnalités et que vous souhaitez exercer toute la suite de tests..
* En attente: (les échecs répertoriés ici sont attendus et n'affectent pas le statut de votre suite) 1) DummyModel ajoute des exemples à (ou supprime) / Users / vis_kid / projects / rspec-test-app / rspec-dummy / spec / models / dummy_model_spec .rb # Pas encore implémenté # ./spec/models/dummy_model_spec.rb:4 Terminé en 0.00083 secondes (le temps de chargement des fichiers a été de 1.94 secondes) 1 exemple, 0 échec, 1 en attente
Toutes nos félicitations! Vous venez de lancer votre premier test RSpec. Pas si mal, n'est-ce pas? Bien sûr, c’était un test factice pour le moment, avec un code test factice généré par Rails. La version plus ciblée de l'exécution de vos tests (vous avez en réalité beaucoup plus d'options que cela seul) consiste à exécuter un fichier individuel, par exemple. Comme ça:
bundle exec rspec spec / models / dummy_model_spec.rb
Cela n'exécutera qu'un seul fichier de test au lieu de la suite de tests complète. Avec des applications plus volumineuses qui dépendent d'un grand nombre de fichiers de test, vous gagnerez du temps. Mais en termes de gain de temps et de spécificité des tests, il ne s'agit que de gratter la surface, pour être franc. Je pense que nous aborderons davantage comment gagner du temps en testant le troisième article de cette série. Voyons jusqu'où nous allons!
L’autre moyen d’exercer toute la suite de tests consiste simplement à exécuter rspec-avec ou sans bundle exec, en fonction de votre configuration.
bundle exec rspec
Une dernière chose que je devrais mentionner avant de poursuivre, vous pouvez également exécuter uniquement un sous-ensemble spécifique de tests. Supposons que vous souhaitiez uniquement exécuter tous vos tests pour votre code de modèle:
bundle exec rspec spec / model
Aussi simple que ça!
Je recommande que nous commencions par les bases simples et que nous examinions quelques options supplémentaires fournies par RSpec dans les deux prochains articles. Jetons un coup d'œil à la structure de base d'un test et plongeons dans des eaux plus avancées lorsque celui-ci est épuisé.
décrireCe sera votre pain et le beurre, car il organise vos spécifications. Vous pouvez référencer des chaînes ou des classes elles-mêmes:
décrivent l'utilisateur ne fin décrivent 'une chaîne' fin
décrire les sections sont les éléments de base pour organiser vos tests en groupes logiques et cohérents à tester. Fondamentalement, une portée pour les différentes parties de votre application que vous souhaitez tester.
décrire l'utilisateur ne… fin décrire l'invité… fin décrire l'attaquant… fin
Un bon conseil est de resserrer encore plus votre oscilloscope. Comme certaines classes vont croître de manière significative, ce n’est pas une bonne idée d’avoir toutes les méthodes que vous voulez tester pour une classe en une seule. décrire bloc. Vous pouvez bien sûr créer plusieurs de ces blocs et les concentrer sur les méthodes d'instance ou de classe. Pour clarifier votre intention, il vous suffit de fournir au nom de la classe une chaîne supplémentaire faisant référence à la méthode à tester..
décrire l'agent, '#favorite_gadget' do… end décrire l'agent, '#favorite_gun' do… end décrire l'agent, '.gambler' do… end
De cette façon, vous obtenez le meilleur des deux mondes. Vous encapsulez des tests connexes dans leurs groupes représentatifs tout en veillant à ce que tout soit concentré et de taille convenable. Pour les utilisateurs très nouveaux sur Ruby Land, je dois mentionner que # fait simplement référence à une méthode d'instance pendant que le point . est réservé aux méthodes de classe. Parce qu’elles sont à l’intérieur de chaînes, elles n’ont pas d’incidences techniques ici, mais elles indiquent votre intention aux autres développeurs et à votre avenir. N'oubliez pas la virgule après le nom de la classe, cela ne fonctionnera pas sans elle! Dans une minute, quand on arrive à attendre, Je vais vous montrer pourquoi cette approche est super pratique.
ilDans le cadre de décrire groupes, nous utilisons un autre domaine de il des blocs. Ceux-ci sont faits pour les exemples réels sous test. Si vous voulez tester la méthode d'instance #favorite_gadget sur le Agent classe, cela ressemblerait à ceci:
décrire Agent, '#favorite_gadget' do it 'renvoie un élément, le gadget favori de l'agent' do… end end
La chaîne que vous fournissez au il block fonctionne comme documentation principale de votre test. Vous y spécifiez exactement le type de comportement souhaité ou attendu de la méthode en question. Ma recommandation est de ne pas exagérer et d'être trop bavard à ce sujet, mais en même temps de ne pas être trop crypté et de confondre les autres avec des descriptions trop intelligentes..
Pensez à ce que la plus petite et la plus simple implémentation de cette partie du puzzle peut et doit accomplir. Mieux vous écrivez cette partie, meilleure sera la documentation globale de votre application. Ne vous précipitez pas sur cette partie car c'est juste une corde qui ne peut pas causer de dégâts, du moins pas à la surface.
attendre()Maintenant, nous allons plus au cœur des choses. Cette méthode vous permet de vérifier ou de falsifier la partie du système que vous souhaitez tester. Revenons à notre exemple précédent et voyons-le en action (limitée):
décris Agent, '#favorite_gadget' do it 'renvoie un élément, le gadget favori de l'agent' do expect (agent.favorite_gadget) .to eq 'Walther PPK' end end
attendre() est la "nouvelle" syntaxe d'assertion de RSpec. Auparavant nous utilisions devrait au lieu. Histoire différente, mais je voulais le mentionner au cas où vous le rencontriez. attendre() s'attend à ce que vous lui fournissiez un objet et que vous utilisiez la méthode testée. Enfin, vous écrivez le résultat affirmé sur le côté droit.
Vous avez la possibilité de choisir la voie positive ou négative avec .à eq ou .not_to eq par exemple (eq être court pour égal bien sûr). Vous pouvez toujours inverser la logique - celle qui vous convient le mieux. Lançons ce test absurde et concentrons-nous sur le résultat obtenu à la suite de la configuration de notre test:
rspec spec / models / agent_spec.rb
Échecs: 1) Agent # favorite_gadget renvoie un élément, le gadget favori de l'agent. Echec / Erreur: attendez (agent.favorite_gadget) .to eq 'Walther PPK'
Lit très bien, n'est-ce pas? ** "Agent # favorite_gadget renvoie un élément et le gadget favori du agent"** vous dit tout ce que vous devez savoir:
Si nous avions laissé la chaîne qui décrit la méthode dans le décrire bloc, la sortie aurait été beaucoup moins claire et lisible:
décris Agent do it 'renvoie un élément, le gadget favori de l'agent' attend (agent.favorite_gadget) .to eq 'Walther PPK' end end
Échecs: 1) L'agent renvoie un élément, le gadget favori de l'agent. Échec / erreur: attendez (agent.favorite_gadget) .to eq 'Walther PPK'
Bien sûr, il existe d'autres moyens de contourner et de traiter ce problème, en passant cette information via votre il bloquer, par exemple, mais l’autre approche est simple et fonctionne. Tout ce qui fait circuler votre sang, bien sûr!
Les meilleures pratiques en matière de test recommandent de composer nos tests en quatre phases distinctes:
Ces quatre phases sont principalement destinées à la lisibilité et à la structuration conventionnelle de vos tests. En gros, il s’agit d’un soi-disant schéma de test, une pratique largement reconnue par la communauté comme étant utile et recommandée. Tout ce sujet de motifs est un trou de lapin profond, alors sachez que je vais laisser de côté un tas pour ne pas confondre à mort les débutants parmi vous.
Lors de l’installation, vous préparez le scénario dans lequel le test est censé être exécuté. Dans la plupart des cas, cela inclura les données nécessaires pour être prêt pour une sorte d'exercice. Petit conseil: ne compliquez pas trop les choses et ne définissez que la quantité minimale nécessaire pour que le test fonctionne.
agent = Agent.create (nom: 'James Bond') mission = Mission.create (nom: 'Moonraker', statut: 'Briefed')
Cette partie exécute en réalité la chose que vous voulez tester dans cette spécification. Pourrait être aussi simple que:
status = mission.agent_status
Vous vérifiez maintenant si votre affirmation concernant le test est satisfaite ou non. Donc, vous testez le système contre vos propres attentes.
attendre (statut) .not_to eq 'MIA')
La structure prend en charge les problèmes de nettoyage de la mémoire et de la base de données - une réinitialisation, en gros. Vous n'avez rien à gérer à ce stade. L'objectif est de retrouver un état vierge pour exécuter de nouveaux tests sans surprises de ceux en cours. Voyons ce que cela signifierait dans un exemple factice:
décrire Agent, '#favorite_gadget' do it 'renvoie un élément, le gadget favori de l'agent' do # Agent de configuration = Agent.create (nom: 'James Bond') q = Quartermaster.create (nom: 'Q') q .technical_briefing (agent) # Exercice favorite_gadget = agent.favorite_gadget # Vérifier ce qui est attendu (favori_gadget) .to eq 'Walther PPK' # Le démantèlement est pour l’essentiel géré par RSpec lui-même.
Comme vous pouvez le constater, dans cet exemple, nous avons séparé l'exercice et vérifié les phases clairement les unes des autres, tandis que dans les autres exemples factices ci-dessus, expect (agent.favorite_gadget) .to eq 'Walther PKK, nous avons mélangé les deux phases ensemble. Les deux sont des scénarios valides et ont leur place. De plus, les nouvelles lignes permettent de séparer visuellement la structure du test..
Maintenant vient la partie difficile, que tester et comment. À mon avis, cet aspect des tests est le plus déroutant pour les nouveaux arrivants - et cela se comprend! Vous êtes nouveau dans le langage et le cadre et souvent vous ne savez même pas encore ce que vous ne savez pas. Comment écrivez-vous des tests pour cela? Très bonne question.
Je serai très franc, vous ne le faites probablement pas et vous ne le ferez pas pendant un bon bout de temps. Se familiariser avec ce genre de choses prend un certain temps. Lorsque vous avez un mentor ou assistez à un camp d'entraînement, vous avez la possibilité d'apprendre directement de personnes expérimentées. Dans ce cas, vos progrès dans ce département seront différents, bien sûr.
D'autre part, si, comme tant d'autres, vous enseignez vous-même ces choses, la patience sera la clé. La lecture de tous les livres et articles vous oriente certainement dans la bonne direction, mais je pense que les tests nécessitent beaucoup de pièces de puzzle plus avancées pour vous donner un sens complet et, peut-être encore plus important, avant que vous ne vous sentiez à l'aise avec cela..
La «bonne» nouvelle est que ce n’est pas inhabituel et que nous sommes tous passés par là. La persévérance est importante. Vous pouvez le faire, ce n’est pas sorcier, mais cela prendra un certain temps avant de pouvoir écrire une application de manière efficace de l’autre côté - du point de vue des tests, je veux dire. Pour le moment, continuez à pousser, amusez-vous, faites des erreurs, écrivez des applications, copiez des tutoriels, etc. jusqu'à ce que l'ampoule s'éteigne.
Lorsque vous écrivez vos tests individuels, vous voulez que leurs objets fassent la chose la plus simple possible pour atteindre votre objectif. Les tests très ciblés sont vraiment essentiels. Vous souhaitez concevoir votre application en suivant des étapes très simples, puis suivre les erreurs que votre suite de tests vous fournit.
N'implémentez que ce qui est nécessaire pour que l'application devienne verte. Pas plus, pas moins! C'est la partie "conduite" dans le développement piloté par les tests. Votre travail est guidé par les besoins de vos tests.
