Certainement une bonne liste. Voici quelques réflexions à ce sujet:
Écrivez d'abord le test, puis le code.
Je suis d'accord, à un niveau élevé. Mais, je serais plus précis: "Écrivez d'abord un test, puis écrivez juste assez de code pour réussir le test et répétez." Sinon, j'aurais peur que mes tests unitaires ressemblent davantage à des tests d'intégration ou d'acceptation.
Concevez des classes à l'aide de l'injection de dépendances.
D'accord. Lorsqu'un objet crée ses propres dépendances, vous n'avez aucun contrôle sur celles-ci. Inversion of Control / Dependency Injection vous donne ce contrôle, vous permettant d'isoler l'objet sous test avec mocks / stubs / etc. C'est ainsi que vous testez des objets de manière isolée.
Séparez le code d'interface utilisateur de son comportement à l'aide de Model-View-Controller ou Model-View-Presenter.
D'accord. Notez que même le présentateur / contrôleur peut être testé à l'aide de DI / IoC, en lui remettant une vue et un modèle stubbed / simulé. Consultez Presenter First TDD pour en savoir plus.
N'écrivez pas de méthodes ou de classes statiques.
Je ne suis pas sûr d'être d'accord avec celui-ci. Il est possible d'effectuer des tests unitaires sur une méthode / classe statique sans utiliser de simulation. Alors, c'est peut-être l'une de ces règles spécifiques à Rhino Mock que vous avez mentionnées.
Programmez des interfaces, pas des classes.
Je suis d'accord, mais pour une raison légèrement différente. Les interfaces offrent une grande flexibilité au développeur de logiciels - au-delà de la simple prise en charge de divers frameworks d'objets fictifs. Par exemple, il n'est pas possible de prendre en charge correctement DI sans interfaces.
Isolez les dépendances externes.
D'accord. Cachez les dépendances externes derrière votre propre façade ou adaptateur (selon le cas) avec une interface. Cela vous permettra d'isoler votre logiciel de la dépendance externe, que ce soit un service Web, une file d'attente, une base de données ou autre. Ceci est particulièrement important lorsque votre équipe ne contrôle pas la dépendance (aka externe).
Marquez comme virtuelles les méthodes que vous souhaitez vous moquer.
C'est une limitation de Rhino Mocks. Dans un environnement qui préfère les stubs codés à la main à un framework d'objet fictif, cela ne serait pas nécessaire.
Et, quelques nouveaux points à considérer:
Utilisez des modèles de conception créatifs. Cela vous aidera avec DI, mais cela vous permettra également d'isoler ce code et de le tester indépendamment de toute autre logique.
Rédiger des tests en utilisant la technique Arrange / Act / Assert de Bill Wake .Cette technique indique très clairement quelle configuration est nécessaire, ce qui est réellement testé et ce qui est attendu.
N'ayez pas peur de rouler vos propres mocks / stubs. Souvent, vous constaterez que l'utilisation de cadres d'objet simulés rend vos tests incroyablement difficiles à lire. En lançant le vôtre, vous aurez un contrôle total sur vos simulacres / stubs, et vous serez en mesure de garder vos tests lisibles. (Reportez-vous au point précédent.)
Évitez la tentation de refactoriser la duplication de vos tests unitaires vers des classes de base abstraites ou des méthodes de configuration / suppression. Cela masque le code de configuration / nettoyage du développeur qui tente de réaliser le test unitaire. Dans ce cas, la clarté de chaque test individuel est plus importante que la refactorisation de la duplication.
Mettre en œuvre l'intégration continue. Enregistrez votre code sur chaque «barre verte». Créez votre logiciel et exécutez votre suite complète de tests unitaires à chaque enregistrement. (Bien sûr, ce n'est pas une pratique de codage en soi; mais c'est un outil incroyable pour garder votre logiciel propre et entièrement intégré.)