Lors de la construction d'une API ou d'une bibliothèque, je fournis souvent des tests d'unité comme une forme de documentation sur la meilleure façon d'utiliser l'API ou la bibliothèque. La plupart du temps, je construis une bibliothèque C #, je fournis à un client qui écrira C # code pour utiliser la bibliothèque.

Pour le bien de la documentation, au moins certains de mes tests seront toujours écrits dans la langue cible.

Le plus grand inconvénient est que vous testez également des dépendances du compilateur dans vos tests unitaires. En un sens, cela en fait également des tests d'intégration. Cela pourrait les rendre préférable si vous vous attendez à ce que votre code soit utilisable de plusieurs langues, mais il ajoute un niveau de complexité que vous n'ayez peut-être pas besoin si votre code ne sera utilisé que si votre code ne sera utilisé que dans la langue qu'elle est développée.

Un avantage que je peux voir, c'est qu'il isole en outre que le code étant développé à partir du test lui-même. En séparant l'acte d'écrire le test encore plus loin du code réel en cours de développement, il vous oblige à considérer comment le code doit être écrit pour réussir le test plutôt que de simplement déplacer le développement initial du code dans le test lui-même.

Je suis un énorme fan des langues de fer, mais il y a des inconvénients significatifs dans les utiliser pour tester un code statiquement compilé. Test Ruby / Python avec Ruby / Python fonctionne bien, c'est-à-dire que vous pouvez simuler des objets de n'importe quel type de manières. Mais les tests C # avec Ruby / Python peuvent entraîner une plus grande complexité que vous pourriez être souhaité.

Considérez un scénario dans lequel vous écrivez un projet ASP MVC où vous souhaitez simuler le type de navigateur. En C #, vous pouvez vous moquer de cela comme ceci (à l'aide de MOQ): p>

class FakeBrowser < HttpBrowserCapabilitiesBase
  def type
    "Fake"
  end
end

class FakeRequest < HttpRequestBase
  def browser
    FakeBrowser.new
  end
end

Je pense que c'est une excellente question et une idée digne de considération - en particulier dans un environnement comme Visual Studio / .NET, où cela est facilement supporté

Le côté plus - comme vous le suggérez - vous pouvez choisir d'utiliser une langue / un outil pour créer des tests plus adaptés à la création de tests que le code que vous utilisez pour créer un code et pour cette seule raison. pensé.

Le côté bas est, comme suggéré, que vos développeurs - ceux qui créent les tests (et nous devons nous rappeler de ne pas confondre les tests de l'unité avec une conception axée sur les tests) devraient probablement parler couramment plus d'une langue (je suggérerais que la capacité d'être si importante est assez importante pour un bon développeur, mais je suis biaisé!) - Et plus important encore, que vous devriez avoir à vous soucier des différences structurelles entre les deux (à nouveau, si vous parlez de langues .net qui devrait être couvert pour vous).

Il devient encore plus intéressant si vous allez au-delà des tests "Unité" aux tests à tous les niveaux où les capacités spécifiques de langues particulières peuvent donner des avantages dans la construction d'un cas de test.

La question ultime est de savoir si les avantages l'emportent sur les inconvénients ... et c'est probablement quelque peu spécifique.

Je suis d'accord avec les autres réponses qu'il y a des inconvénients, mais je suis surpris que si peu d'avantages ont parlé des avantages.

• TDD'ing à travers les langues est un excellent moyen d'apprendre de nouvelles langues: écrivez les tests dans une langue que vous connaissez bien et la mise en œuvre dans la langue que vous apprenez. Comme vous apprenez, vous découvrirez de meilleures façons d'écrire le code que vous l'avez fait, mais le refactoring est facile, car vous avez une suite de test.
• Avoir à maîtriser plusieurs langues vous garde (et votre équipe) Sharp.
• Vous obtenez une meilleure vérification que votre API est interopérable entre les langues.

Expérience 1

Au cours de la dernière année, j'ai travaillé sur un projet qui avait deux pièces principales:

1. une application Web GRAVES
2. et une application Java Swing

   Nous avons écrit nos tests de l'unité Java à l'aide de Groovy et cela a bien fonctionné. Les tests unitaires avec Groovy ont pris beaucoup moins de temps verbosité sage et ont également permis de fausses méthodes statiques et ainsi de suite. Bien qu'il y ait eu quelques endroits où nous avons rencontré des résultats inattendus dus à la dactylographie dynamique de Groovy, dans l'ensemble, c'était une expérience positive.

   Expérience 2

   Un autre projet récent sur lequel j'ai travaillé était une application Web C # ASP.NET MVC 3 où j'ai écrit tous les tests de l'unité avec F #. J'ai choisi c # pour l'application Web car je sentais que cela fonctionnait mieux avec MVC 3. J'ai choisi F # pour des tests unitaires car c'est ma langue préférée. Les seuls problèmes que j'ai rencontrés étaient des ennuis mineurs avec des types tels que null vs. option .

   Conclusion

   Lorsque nous avons deux langues ciblant le même runtime (Eh bien, C # / F # et Java / Groovy sur CLR et JRE sur CLR et JRE) Où l'on est utilisé pour le code de production et une pour les tests d'unités, il n'ya pas trop de choses à craindre en ce qui concerne la compatibilité au moins. Ensuite, je pense que c'est vraiment une question de savoir si vous et votre équipe vous sentez assez à l'aise dans les deux langues (et je suppose que vous pourriez être assez gentille pour envisager de futurs responsables). En effet, je pense que les moments où vous seriez obligé d'utiliser une langue différente pour les tests unitaires est lorsque la langue de test de l'unité est en réalité votre langue de confort ou de choix sur votre langue de production.

   Il y a quelques exceptions que j'avais admettre à cette attitude libérale. Si vous concevez une bibliothèque à consommer par langue x, il peut s'agir d'une idée intelligente d'écrire vos tests d'unité dans la langue x (au moins). Mais pour le code d'application, je n'ai jamais trouvé de tests d'unité d'écriture dans la même langue que votre code de production particulièrement avantageux.