J'ai créé quelques petites interfaces courantes grâce à une chaîne de méthode. Ils appellent généralement un certain nombre de référentiels qui récupèrent des données de webservices / bases de données.
Comment devrais-je aller sur des méthodes de test unitaires qui utilisent l'interface fluide? P>
Public IEnumberable<Computer> FindComputers(string serialNumber)
{
return Computers.FindBySerialNumber("YBCX00900")
.AttachConfiguration()
.EnsureAllComputersHaveConfiguration();
}
3 Réponses :
je ferais 2 + 3. En supposant que les interfaces courantes soient des interfaces, elles doivent être relativement simples à moquer. Il suffit de réaliser que chaque étape de la chaîne d'appels devrait probablement retourner un nouvel objet simulé, qui s'attend à son tour dans la chaîne.
Vous devez toujours tester l'interface fluide directement, moqueur de la couche de référentiel sous eux.
Merci pour l'entrée, j'ai pensé à se moquer de l'interface fluide elle-même, mais cela semble étrange d'écrire des tests comme ... Attendez-vous (x => x.findbyserialnumber (null)). Retour (x => x. FixationConfiguration ()). Retour (NextMock) Lorsque tout ce qui est testé est que les appels sont réellement effectués. Il est beaucoup de travail pour recréer toute l'interface fluide dans des objets simulés, uniquement pour tester ce qui est déjà clairement écrit dans la méthode testée.
Je suis nouveau pour faire une couverture de test unitaire et avoir parfois les mêmes qualifications. Bien que c'est facile à examiner le code par inspection, c'est encore un examen manuel. Ajout de la couverture de test vous permet de vous protéger sur la route lorsque vous ne pensez plus à cette classe. Cela peut également indiquer que l'interface fluide est plus compliquée qu'elle n'a besoin que, si l'interface était plus concentrée sur ce dont vous avez besoin, les tests seraient plus simples pour écrire également.
Pouvez-vous vous moquer de vos référentiels? Bien que certains préconisent une approche plus pure où vous devez isoler une méthode d'une classe, il serait un moyen décent de tester la manière dont les résultats de recherche et l'interface fluide fonctionnent ensemble. Et il peut être plus simple, en fonction de la couche d'accès au référentiel ressemble à.
Je pense que la fi est en train de faire plus que nécessaire. Je suppose que vous utilisez des ordinateurs comme mappeur de données et utilisez-le également pour la construction d'une requête. De ce que vous avez montré que la requête est construite à partir de ceci: et ainsi de suite ... Maintenant certaines de ces règles pouvant être implémentées semblent être incorrectes . La règle 2 et la règle 3 semblent être à des fins croisées. Règle 5 et règle 6 fait quoi? Est-ce à propos de droite? parce que vous avez mis en œuvre un objet qui enfreint SRP. La première étape consiste à casser le constructeur de requêtes à partir du mappeur de données. Construisez votre objet de fi requête puis transmettez-le dans le mappeur. Vous pouvez désormais tester Recherdcomputers Assurez-vous que l'objet de fi requête est envoyé à une mappeuse de données. Parce que vous pouvez maintenant créer un objet de fi requête, vous pouvez le tester. Et vous pouvez tester que la mappeuse de données utilise un objet de requête. Et si vous voulez trouver des ordinateurs par emplacement. Si vous gardez le même code que vous avez écrit, vous devez ajouter une méthode EnsachbyLocation et avant de savoir que vous avez un objet de Dieu. SMLLY!
Merci, vous avez raison, l'exemple est mal pensé, j'ai depuis brisé la fi en une pour la requête et une tâche pour effectuer des opérations sur les données retournées. J'ai trouvé que cela est le plus facile à tester l'isolement de l'unité, puis des méthodes de test unitaire utilisant la fi avec la mise en œuvre concrète. Il suffit de tester que le résultat souhaité est renvoyé. Essayer de se moquer de la fi, rend les tests trop fragiles.