état Test en S # arp Architecture - Les meilleures pratiques

Question

Comment puis-je tester pour l'état dans un S # arp projet d'architecture?

Par exemple, j'ai un RoleProvider personnalisé. Je veux tester la méthode provider.AddUsersToRoles (string [], string []).

Alors je commence par:

// Arrange
const string ficticiousRole = "Management";
var userToExpect = UserInstanceFactory.CreateValidTransientUser();
var roleToExpect = RoleInstanceFactory.CreateValidTransientRole();

userRepository.Expect(r => r.GetByUsername(userToExpect.Username))
              .Return(userToExpect);
roleRepository.Expect(r => r.GetByName(ficticiousRole))
              .Return(roleToExpect);

var userNames = new List<string>();
var roleNames = new List<string>();
userNames.Add(userToExpect.Username);
roleNames.Add(ficticiousRole);

Ensuite, j'ajouter l'utilisateur à un rôle. Ensuite, je vérifie si l'utilisateur est dans ce rôle.

// Act
roleProvider.AddUsersToRoles(userNames.ToArray(), roleNames.ToArray());
var isNewUserInRole = roleProvider.IsUserInRole(userToExpect.Username, ficticiousRole);

// Assert
Assert.IsTrue(isNewUserInRole);

Le problème est que j'utilise Rhino Mocks. J'ai une connaissance limitée de Rhino Mocks, mais d'après ce que je comprends (selon Ayende Rahien) que vous utilisez Rhino Mocks pour tester les opérations, pas d'état.

Je suppose un SqlLite db en mémoire serait plus approprié? Quelle est la meilleure façon de le faire en S # arp Arch?

Answer 1

Vous ne pouvez pas le faire avec Rhino Mocks puisque c'est tout simplement un cadre moqueur que les choses de fakes comme des appels de base de données, etc. Il semble que vous voulez réellement à la persistance de test à la base de données qui est essentiellement des tests d'intégration de base de données. Dans ce cas, vous voudrez certainement plus d'utiliser une base de données en mémoire telles que SqlLite (si possible!) Plutôt que de frapper une instance SQL Server.

Qu'est-ce que vous voulez faire est au début de chaque classe de test ou un test est la base de données démontage si elle existe déjà, la reconstruction de la base de données, remplir la base avec des données de semences puis testez votre interaction de base de données. De cette façon, vous pouvez vous assurer que vous avez un état de base de données connue avant chaque test est exécuté.

Une chose que je l'ai fait sur un projet a été regroupé tous mes tests en lecture seule dans une classe de test pour que je ne devais faire la base de données reconstruire étape une fois pour la classe et déplacé toute ma suppression, mise à jour et insérer des tests dans d'autres cours d'essai qui reconstruit la base de données avant chaque essai. Compte tenu de suffisamment de tests, cela peut être assez de temps et peut vouloir être relégué au serveur CI.

Answer 2

Sans voir le reste de votre code, il serait difficile de répondre.