Il semble exceptionnellement lourdement lourd, mais aller par la règle tout ce qui est disponible publiquement doit être testé em> devrait [TestClass]
public class CustomerTests : TestClassBase
{
[TestMethod]
public void CanSetCustomerEmailAddress()
{
//Arrange
Customer customer = new Customer();
//Act
customer.EmailAddr = "foo@bar.com";
//Assert
Assert.AreEqual("foo@bar.com", customer.EmailAddr);
}
}
5 Réponses :
Cela dépend si vous testez qu'une API est conforme à un ensemble de propriétés prévu, ou si, comme vous le démontrez, vous ne faites que tester et définir les propriétés.
Dans l'exemple que vous donnez, je dirais non.
mise à jour
se conformer à l'API prévue; Si vous accédez aux propriétés indirectement, dites-vous dans un environnement de réflexion / dynamique et que vous utilisez des appels d'accès à la propriété et à la méthode pour vérifier une API inconnue conforme à une utilisation attendue.
Pouvez-vous élaborer sur ce que vous entendez en «testant qu'une API est conforme à un ensemble de propriétés attendu»?
Que se passe-t-il si vous passez des propriétés appliquées automatiquement à quelque chose de tout à fait différent? Le test semble seulement redondant, car vous connaissez la mise en œuvre - que vous ne devriez pas envisager lors de la rédaction de tests.
Bien sûr, cela dépend de la probabilité de votre modification de la mise en œuvre à tout moment.
Si cela devait arriver, cependant, vous le feriez en écrivant un test d'abord à droite? Alors, il serait testé. Au moins si vous faites votre TDD ce serait la façon dont cela fonctionnerait. Nous savons tous que les gens n'écrivent pas toujours leurs tests d'abord.
+1 pour l'aspect de la régression. C'est une propriété auto aujourd'hui mais demain, il peut avoir besoin de modifier pour soutenir les nouvelles caractéristiques de classe, etc.
Je considère généralement n'importe quel code qui n'effectue pas d'action pour ne pas avoir la peine d'être testé. Cela signifie généralement que je ne testez pas les propriétés (mise en œuvre automatique ou non) car elles ne sont que définissent ou renvoyant une valeur.
Ceci changera si le getter ou la séchure d'une propriété effectue une sorte de "travail", comme étant éventuellement renvoyé l'une des deux valeurs (ou plus) basées sur l'état d'un autre champ / propriété / autre.
Si vous ne l'avez pas vu, je recommande vivement osherove's href = "http: //artofunittesting.com/ "rel =" noreferrer "> Réservez sur le test de l'unité . Il aborde toutes sortes de questions de type "à tester et à", y compris celui-ci.
Test d'une propriété automatique teste le cadre, pas votre code: il n'y a pas de code logique de code à vérifier. Et si vous avez fini par ajouter de code derrière la propriété, vous devriez voir la couverture de test descendre, ce qui indiquera qu'il est maintenant temps de tester cette propriété.
C'est encore plus simple que de voir la couverture de test descendre ... Comme je l'ai commenté dans l'autre réponse, si vous changez du code, il fait donc quelque chose d'autre qu'une propriété automatique, ce changement devrait être piloté par un test, de sorte que vous allez à Ce point soit testant ce changement de fonctionnalité.
Les tests unitaires doivent être confinés pour tester la fonctionnalité que vous exécutez dans votre application.
Vous ne devez pas tester l'API / SDK que votre demande repose sur. Partiellement parce que c'est une perte de temps (votre entreprise veut-elle payer pour vous de tester le SDK / API de X-tiers?), Et en partie parce qu'il introduit "bruit" dans votre suite de tests d'unité. Le contexte de votre bibliothèque de test de l'unité doit être de ne pas tester que le code de votre application.
client est une classe que nous possédons.
@ahsteele, vrai mais votre test ne teste sans doute que le comportement du compilateur C #.
@Yishai a accepté, en relisant la réponse que je vois ce que Guerriorpostman conduisait à.
Le réglage des tests et les propriétés devraient se produire dans le contexte de tester une fonction d'entreprise de l'objet. S'il n'y a pas de fonction commerciale teste la propriété, vous n'avez pas besoin de la propriété ou si vous avez besoin de plus de tests. Je suggérerais que vous ajoutez les propriétés lorsque vous ajoutez les tests qui en ont besoin plutôt que de les ajouter avant d'écrire des tests.
En test de la fonction Business, vous traitez le code autant plus d'une boîte noire du point de vue du test de l'unité. Cela vous permet de changer les détails de la mise en œuvre ci-dessous avec un impact beaucoup moins important sur les tests. Au fur et à mesure que le refacteur est une étape importante (et souvent négligée) du cycle TDD, cela signifie beaucoup moins d'édition de code. Vous pouvez également concrétiser que (par exemple) la propriété ne doit pas avoir de secteur public et doit être attribuée par une méthode qui effectue une validation et une autre logique commerciale.