Les autres réponses sont très bonnes, mais elles n'enseignent que des trucs super basiques. Ils ne rentrent pas dans les détails sur les tests des completionHandlers, les appels réseau, les contrôleurs, comment mocker, etc.
Je ne suis pas allé complètement TDD, mais j'ai eu cette question il y a quelques mois. J'avais pour objectif d'apprendre cela, car je savais que c'était quelque chose que les recruteurs auraient aimé et que cela améliore la qualité de mon propre code.
Mais le problème était que je ne connaissais pas assez Swift. Je n'étais pas assez à l'aise/expérimenté pour écrire rapidement des délégués, des completionHandlers, ou pour traiter/comprendre les problèmes de multithreading.
Maintenant, je suis plus capable. Mais j'ai alors un autre problème ! C'est-à-dire, comment écrire du code modulaire et ne pas fuir les choses qui doivent être dans votre vue ou votre modèle, vers la couche contrôleur.
Alors actuellement en ce moment, j'essaie de ne rien fuir vers le contrôleur. Ce qui signifie que vous devez soit faire MVC de la bonne façon (ce qui aurait encore quelques problèmes) ou faire MVVM.
Jusqu'à ce que vous ne connaissiez pas assez Swift et que vous puissiez venir avec une bonne architecture de code, je vous suggère de ne pas essayer TDD. Il m'a fallu à peu près 1 an pour acquérir l'expérience nécessaire pour commencer le TDD.
Pour ce qui est des sources :
- Pour commencer, comprenez TDD red green refractor cycle écrit par Yvette Cook. En gros, l'essentiel est :
en supposant que nous avons du code de 'production' et du code de 'test'
Sans écrire une seule ligne de code de production, j'écris d'abord un test. Je ne commence aucun code de production. Je n'écris du code de production que si mes tests échouent (rouge). Une fois mes tests réussis (vert), j'ajoute d'autres tests, ce qui signifie à nouveau du rouge, ce qui signifie à nouveau que je dois écrire du code de production pour que les tests réussissent (vert). Ce cycle se termine une fois que j'ai toutes les fonctionnalités de mon unité. (Bien que vous ne pouvez et ne devriez jamais avoir une couverture de code de 100%, c'est stupide, mais généralement plus il y en a, mieux c'est !)
- J'ai lu Test-Driven iOS Development with Swift. Ce livre est génial. C'est avec ce livre que j'ai le plus appris. Il vaut son prix. Il m'a également aidé à améliorer à la fois mes compétences en architecture et mes compétences en Swift. Il vous aide à écrire des tests liés aux appels ViewControllers/Network et vous aide à mocker vos classes.
- Voir cette réponse et la vidéo à laquelle elle renvoie : Qu'est-ce que le mocking ? La vidéo vous aide également à améliorer vos compétences en matière d'architecture.
Il existe également des tests d'interface utilisateur qui sont différents, spécialement en ce qui concerne les apps qui sont pilotées par les réponses qu'elles obtiennent d'un appel réseau. Mais cela ne ferait qu'augmenter la portée de la question et je devrais parler de choses dont mes connaissances sont insuffisantes.
.