Prüfadapter oder ähnliches für Testdaten mit Smalltalk Seaside?

Question

Ich habe Test Driven Development in einer Seaside-App verwendet, mit der ich gespielt habe, und alle meine Daten werden als Objekte im Bild gespeichert (im Gegensatz zu einer Datenbank).

Also, wenn ich meine Tests ausführen Ich habe die realen Daten vorsichtig sein, weg zu speichern, bevor sie mit Testdaten, wie diese im Papierkorb wird:

ToDoTest>>setUp 
    savedTasks := Task tasklist. 
    Task deleteAllTasks. 

    savedProjects := ToDoProject projectlist. 
    ToDoProject deleteAllProjects. 

    savedPeople := Person peoplelist. 
    Person deleteAllPeople. 

Und:

ToDoTest>>tearDown 
    Task tasklist: savedTasks. 
    ToDoProject projectlist: savedProjects. 
    Person peoplelist: savedPeople 

Das Problem kommt, wenn meine Tests fehlschlagen, was sie natürlich tun, das öffnet den Debugger, und ich kann dann wegräumen, aber das TearDown wird nicht immer aufgerufen und so kann ich meine echten Daten verlieren.

Ich speichere die Daten in Dateien, also ist es kein großes Problem, aber es ist nicht so glatt und automatisiert, wie ich es gerne hätte.

Wie auch immer ich kann das verbessern?

Answer 1

Ich bin mir nicht sicher, ob es ein Szenario gibt, das das Problem vollständig beheben wird. Das eigentliche Problem ist, dass das Modell global ist. Das ist praktisch und schön, aber es fällt in einem solchen Szenario leicht. Ich würde also erwägen, das Modell von einer globalen auf eine lokalisiertere Variante zu ändern, damit Sie Ihr Modell ausschließlich zu Testzwecken erstellen können, ohne die Produktionsdaten zu beeinträchtigen.

Um es in Ihrem aktuellen Setup zu beheben, müssen Sie eine Sicherung hinzufügen: irgendwo blockieren. Ein Sicherheitsblock "stellt" sicher, dass etwas ausgeführt wird, unabhängig davon, ob alles in Ordnung war oder ein Fehler aufgetreten ist. Das Problem ist, dass Sie es vor und nach einem Test tun müssen.

In diesem Fall würde ich Testcase >> # runCase in Ihrer eigenen Testklasse mit so etwas wie

runCase 
    [ self saveRealModel. 
     super runCase ] 
     ensure: [ self restoreRealModel ] 

Answer 2

Ah, das ist ein schöner Test Geruch zu überschreiben. Norbert weist mit Recht darauf hin, dass das getestete Modell wahrscheinlich nicht global sein sollte. Die meisten Tests sollten sich auf die Interaktion zwischen einzelnen Objekten beziehen. in der Storyboard haben wir die Nutzer

DEUser subclass: #SBUser 
    instanceVariableNames: 'email initials projects invitations' 
    classVariableNames: '' 
    poolDictionaries: '' 
    category: 'StoryBoard-Data' 

mit Klasse instancevar Benutzer als Einstiegspunkt. Projekte sind nur über die Benutzer erreichbar.

users 
    ^users ifNil: [ users := OrderedCollection with: (SBAdministrator new 
     userid: 'admin'; 
     password: 'admin'; 
     yourself) 
    ] 

und ein Weg, um sie

resetUsers 
    " SBUser resetUsers " 
    users := nil 

Oft löschen wir in Abhängigkeiten von Schöpfung passieren kann für Domain

Iteration>on: aProject 
    ^self new 
     project: aProject; 
     yourself 

Objekte

Dies ist ein Testfall an sich passieren lässt oder eine separate (Mock) Objekt