Dispositivi di prova o equivalenti per i dati di prova con Smalltalk Seaside?

Question

Ho utilizzato Test Driven Development in un'app Seaside con cui ho giocato e tutti i miei dati sono archiviati come oggetti nell'immagine (al contrario di un database).

Così, quando ho eseguito i miei test ho dovuto fare attenzione a riporre i dati reali prima che venga cestinato con dati di test, in questo modo:

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

    savedProjects := ToDoProject projectlist. 
    ToDoProject deleteAllProjects. 

    savedPeople := Person peoplelist. 
    Person deleteAllPeople. 

E:

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

Il problema si presenta quando i miei test falliscono, il che ovviamente succede, questo fa apparire il debugger e posso ripararlo, ma il tearDown non viene sempre chiamato e quindi posso perdere i miei dati reali.

Salvare i dati nei file, quindi non è un problema enorme, ma non è così semplice e automatizzato come mi piacerebbe che fosse.

In ogni caso posso migliorare questo?

Answer 1

Non sono sicuro se esiste uno scenario che risolverà il problema completamente. Il vero problema è che il modello è globale. Questo è comodo e piacevole ma fallisce facilmente all'interno di uno scenario del genere. Quindi, prenderei in considerazione la possibilità di cambiare il modello da qualcosa di globale a una variante più localizzata in modo da poter creare il modello esclusivamente per scopi di test senza interferire con i dati di produzione.

Per risolvere il problema nella configurazione corrente è necessario aggiungere un blocco: bloccare da qualche parte. Un blocco assicura che "ti assicura che qualcosa venga eseguito, indipendentemente dal fatto che tutto sia andato a posto o che si sia verificato un errore. Il problema è che devi farlo prima e dopo un test.

In questo caso mi sarebbe sovrascrivere TestCase >> # runCase nella propria classe di test con qualcosa di simile

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

Answer 2

Ah, questo è un buon profumo di prova. Norbert ha ragione nel sottolineare che il modello testato probabilmente non dovrebbe essere globale. La maggior parte dei test dovrebbe essere sull'interazione tra singoli oggetti. In StoryBoard Abbiamo utenti

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

con gli utenti di classe instancevar come un entrypoint. I progetti sono accessibili solo attraverso gli utenti.

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

e un modo per eliminarli

resetUsers 
    " SBUser resetUsers " 
    users := nil 

Spesso ci possono passare in dipendenze sulla creazione di oggetti di dominio

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

Questo permette un testcase di passare in sé o un separato (simulazione) oggetto