Teststatus in S # arp Architektur - Best Practice

Question

Wie kann ich den Status in einem S # arp Architecture-Projekt testen?

Zum Beispiel habe ich einen benutzerdefinierten RoleProvider. Ich möchte die Methode provider.AddUsersToRoles (string [], string []) testen.

So beginne ich mit:

// 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); 

Dann habe ich den Benutzer zu einer Rolle hinzuzufügen. Dann überprüfe ich, ob der Benutzer in dieser Rolle ist.

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

// Assert 
Assert.IsTrue(isNewUserInRole); 

Das Problem ist, dass ich Rhino Mocks benutze. Ich habe nur begrenzte Kenntnisse über Rhino Mocks, aber von dem, was ich verstehe (nach Ayende Rahien), benutzt du Rhino Mocks, um auf Operationen zu testen, nicht auf Zustände.

Also ich denke, eine In-Memory SqlLite db wäre besser geeignet? Was ist der beste Weg, dies in S # arp Arch zu tun?

Answer 1

Das können Sie mit Rhino Mocks nicht tun, da das einfach ein spöttisches Framework ist, das Dinge wie Datenbankaufrufe usw. vortäuscht. Es klingt, als ob Sie die Persistenz wirklich auf die Datenbank testen wollen, was im Grunde Datenbankintegrationstests ist. In diesem Fall würden Sie definitiv eine speicherinterne Datenbank wie SqlLite (wenn möglich!) Anstelle einer SQL Server-Instanz verwenden wollen.

Was Sie tun möchten, ist am Anfang jedes Tests oder Test-Klasse ist die Datenbank abreißen, wenn es bereits vorhanden ist, erstellen Sie die Datenbank neu, füllen Sie die Datenbank mit einigen Seed-Daten und testen Sie dann Ihre Datenbankinteraktion. Auf diese Weise können Sie sicherstellen, dass Sie einen bekannten Datenbankstatus vor jedem Test haben.

Eine Sache, die ich bei einem Projekt gemacht habe, waren alle meine schreibgeschützten Tests in einer Testklasse zusammengefasst, so dass ich den Datenbankwiederherstellungsschritt nur einmal für die Klasse durchführen musste und alle meine Lösch-, Update- und Einfügetests in verschoben hatte andere Testklassen, die die Datenbank vor jedem Test neu erstellten. Bei genügend Tests kann dies ziemlich zeitaufwändig sein und möglicherweise auf den CI-Server übertragen werden.

Answer 2

Ohne den Rest Ihres Codes zu sehen, wäre es schwierig, dies zu beantworten.