Je lis actuellement un livre (Framework Pro ASP.NET).
Dans ce livre, l'auteur suggère d'utiliser un Framework MOQ pour aider à faire TDD. P>
[Test]
public void List_Presents_Correct_Page_Of_Products()
{
IProductsRepository repository = MockProductsRepository(
new Product { Name = "P1" }, new Product { Name = "P2" },
new Product { Name = "P3" }, new Product { Name = "P4" },
new Product { Name = "P5" }
);
ProductsController controller = new ProductsController(repository);
...
}
static IProductsRepository MockProductsRepository(params Product[] prods)
{
// Generate an implementor of IProductsRepository at runtime using Moq
var mockProductsRepos = new Moq.Mock<IProductsRepository>();
mockProductsRepos.Setup(x => x.Products).Returns(prods.AsQueryable());
return mockProductsRepos.Object;
}
5 Réponses :
Certains avantages de frameworks simultanés sur des simulacres laminés à la main:
Quelques inconvénients:
(Voici ce que je peux penser en ce moment. N'hésitez pas à éditer et à ajouter plus.)
Le référentiel simulé peut être utilisé pour générer des exceptions aussi, plutôt que de modifier le faux référentiel dans l'obscurité.
Nous l'utilisons pour effectuer essentiellement un faux serveur dans un environnement client / serveur.
De cette façon, les appels n'ont pas besoin d'aller jusqu'au client sur le serveur à la DB et à nouveau. Ils vont simplement sur le serveur simulé, qui est dit de renvoyer un certain objet / valeur pour un appel donné et s'attendre à ce que certains appels soient faits.
Et pourquoi utiliser MOQ au lieu d'écrire une classe Fakeerver à la main?
Nous avons déjà le serveur écrit sur une interface spécifique. La moqueur se remplit essentiellement dans les talons pour les méthodes que nous n'utilisons pas. Si nous voulons seulement tester une ou deux méthodes, nous n'avons pas à créer une implémentation complète de l'interface.
Un cadre moqueur vous relege du fardeau de la création d'objets maquets uniques, qui renvoient des données spécifiques à votre cas de test. Ils permettent également de vérifier si certaines méthodes ou propriétés ont été consultées ou modifiées (par les consommateurs de l'objet simulé). Cela vous permet de tester plus facilement et d'appliquer ainsi certains comportements attendus.
Les cadres de simulation ne sont que des outils. Bien sûr, vous pourriez le faire manuellement, mais vous pouvez vous trouver de passer du temps à maintenir des cours qui ne sont que pour les tests.
Une question similaire est disponible ici .
Vous voudrez peut-être lire ceci moqueur manuel: résister à l'invasion des points et des parenthèses
Le site de mentor d'objet n'est plus vivant, le lien ci-dessus ne fonctionne pas. Trouvé une copie de l'article ici: sites.google.com/site/unclebobconsultingllc/home/articles/...
Mocking vous permet de contrôler l'entrée en vigueur pour vérifier que la sortie se produit correctement. Par exemple, vous pouvez transmettre des données que vous connaissez une erreur, puis de tester que vos méthodes jettent réellement cette erreur et vous pouvez transmettre des données valides et tester que les données valides sont renvoyées de l'objet.
Il y a plus de cadres que Just Moq; Il y a des rhinomocks et Typemock (mon préféré personnel, même si cela coûte de l'argent, à moins que ce soit un projet open source) pour n'en nommer que quelques-uns.