Meilleure réponse
Je travaille actuellement pour AutoTrader, qui le fait très bien, à mon avis.
Nous vous asseyons juste devant un ordinateur portable, avec un moniteur et un clavier / souris plus grands, en association avec lun de nos développeurs seniors et observés par un autre développeur senior.
Cest assez amusant pour tout le monde, sauf les nerfs habituels des entretiens, et le fait que vous rencontrez de nouvelles personnes. Mais certainement, quand je suis votre paire, jessaie davoir un peu de rapport amical, de vous faire sentir le bienvenu et ainsi de suite. Tout comme je le ferais normalement. En fait, je veux que vous réussissiez.
Vous obtenez une demi-page de description du problème d’une tâche simple. Et puis vous faites un peu de programmation par paires.
Il y a plusieurs choses observées et notées:
- Ecrivez-vous les tests en premier? Après le code? Jamais?
- Utilisez-vous des tests pour réfléchir à la conception?
- Nommez-vous les choses clairement?
- Préférez-vous la POO, la programmation procédurale – ou juste une fonction énorme?
- Interagissez-vous bien avec la paire? Ou même pas du tout?
- Expliquez-vous votre réflexion au fur et à mesure et invitez-vous les deux à contribuer? Ou rester en silence?
- Utilisez-vous des fonctionnalités standard de Java, comme les collections? Sinon, que faites-vous?
- Utilisez-vous bien lEDI (qui est de votre choix)?
- Avez-vous bien réparti le problème? Pauvrement? Pas du tout?
Si vous pouvez faire du Java, du TDD et / ou de la conception pour faire des tests unitaires et que vous semblez être un tri raisonnablement personnalisable, vous avez tendance à obtenir un score élevé.
Ce test ne concerne pas la connaissance des fonctionnalités de langage étranges, ou la connaissance des algorithmes étranges, ou même la résolution du problème.
Il sagit de voir comment vous utilisez ces choses que vous avez écrites sur votre CV dans la vraie vie.
Vous lapprécierez vraiment. Cela donne à tout le monde une image fidèle de lendroit où se trouve un candidat.
Cela élimine aussi impitoyablement les fausses demandes de CV.
Dites-vous que vous faites du TDD? Vous ne savez pas ce que signifie «affirmer»? Oh cher. Vous dites que vous maîtrisez la POO? Tout le code, qui ne fonctionne pas, est dans la même méthode que le test unitaire que nous avons fourni? Oh mon Dieu.
(Et oui, cest vraiment arrivé).
Pour moi, cela a été une révélation dêtre des deux côtés de ce processus.
Réponse
TDD est un outil. Ce qui ne va pas, cest que traite le TDD comme une religion.
Le TDD est généralement effectué avec des tests unitaires: tests de petites pièces ou fonctions (« unités » ) de votre code. Les tests unitaires sont censés sexécuter rapidement , donc vous simulez généralement toutes les dépendances de services externes et assurez-vous simplement que le code lui-même est testé.
Le problème de énorme-éléphant-dans-la-pièce est que parfois les services externes dont vous vous êtes moqués contiennent la plupart de la logique dune fonction. Si votre « unité » saisit un élément dune base de données à laide dune requête et le renvoie, se moquant de cette interaction est à 100\% inutile sauf comme un substitut à la vérification de type.
Je le répète dune manière différente: Les soi-disant «leaders dopinion »Qui prêchent lévangile du TDD prêchent aussi fréquemment lévangile des langues dynamiques. Les langues quils vous disent sont donc beaucoup plus productives nécessitent en fait beaucoup plus de travail pour tester, et souvent pour réécrire ces tests lorsque vous avez besoin de refactoriser.
Écrivez votre code dans un langage plus sûr comme C #, Java ou TypeScript, et vous ne le faites pas. Vous devez vous soucier de vérifier que les types sont toujours valides. Et il y a tonnes davantages réels à utiliser des langages de type statique en plus de ne pas avoir besoin décrire des tests qui ne testent en fait rien.
Alors quest-ce que jentends vraiment par les tests «ne rien tester»? Supposons que vous ayez une fonction qui effectue une requête SQL sur votre base de données. Il est censé rechercher les éléments filtrés par un champ particulier. Afin décrire un test unitaire rapide, vous vous moquez de la requête SQL. À moins que votre bibliothèque fictive ne puisse réellement simuler toute la logique de PostgreSQL fonctionnant sur un exemple de jeu de données, la logique de base réelle de votre fonction n’est pas du tout testée ; les seuls tests de fond que vous pourriez écrire pour vérifier la logique valideraient uniquement que vos se moquent renvoient des réponses appropriées.
Je vois souvent des moqueries que simplement « vérifier que la base de données a été appelée le bon nombre de fois. » Cela vous donnerait votre couverture de code à 100\%, après tout! Génial, un numéro pour impressionner les managers non techniques qui ne veut absolument rien dire en pratique! Allez dans léquipe Statistiques trompeuses!
Non, ce dont vous avez besoin, ce sont des tests système, ou des tests dintégration / E2E, pour valider que lensemble de votre système est travail. Pas seulement des tests unitaires, mais des tests qui ne se moquent pas des appels à la base de données, mais effectuent plutôt ces appels.Et lorsquune suite de tests a besoin de mettre en place une base de données de tests réelle, de leffacer et de la semer entre les tests, cela rend le TDD en tant que pratique impraticable; cest trop lent.
Alors continuez et écrivez dabord le code, puis écrivez votre test E2E et assurez-vous quil donne le bon résultat. Heck, vous pouvez utiliser la fonction dinstantané de suites de tests comme Jesthttps: //jestjs.io/docs/en/snapshot-testing pour simplement valider que la réponse ne change pas; regardez-le une fois pour vous assurer quil est correct, puis après avoir dit à Jest quil a raison, il validera quil restera le même dans les prochaines exécutions! Les API peuvent être testées, et leurs tests mis à jour, de manière presque automatisée!
Donc, si vous ignorez les délires des fidèles TDD, vous pouvez faire votre travail deux fois plus vite car vous nen avez pas besoin attendre 10 minutes (ou plus! Jai vu une suite de tests qui a pris plus dune heure…) pour que la suite E2E complète sexécute afin de voir le test échouer avant de commencer à écrire votre code.
De plus, tester linterface du tout , comme indiqué dans la réponse de Moray Taylor, est peu pratique dans de nombreuses circonstances. Il existe un certain niveau de test E2E qui peut être appliqué à linterface utilisateur, mais pour la plupart, le retour sur investissement en vaut rarement la peine dans le cas général.
Cela dit, je travaillais sur une bibliothèque graphique une fois qui était utilisée par plus dune centaine de jeux vidéo différents, et jai écrit un test E2E suite pour valider quun changement dans la logique interne de la bibliothèque ne briserait pas un jeu obscur que je navais même jamais vu. Les bibliothèques méritent toujours des tests plus approfondis. Mais pour linterface utilisateur dune seule application, les tests E2E nont presque jamais de sens dans mon expérience.