Calendario, test e condizioni preliminari

Question

Calendario, test e condizioni preliminari

#1 da (1 voti)

1

Quando usi le fabbriche, anche se è necessario lavorare di più in anticipo, sai che imposterai le pre-condizioni corrette per il test (fino a ciò che hai scritto). Tuttavia, quando usi le fixture, anche se nessun lavoro è richiesto per impostare lo stato del database, qualcuno (incluso lo sviluppatore del test) potrebbe facilmente cambiare i proiettori in un modo o nell'altro in futuro e rendere il test inutile (ad esempio, fare in modo che passi sempre qualunque cosa!)

In che modo dovrebbe proteggersi da questo per proteggere l'integrità del test in futuro? Dovrebbero essere asserite le condizioni preliminari prima dell'esecuzione del test? Questa è considerata la migliore pratica?

testing unit-testing integration-tests

posta Adam Thompson 28.04.2018 - 02:21

fonte

1 risposta

Leggi altre domande sui tag testing unit-testing integration-tests

Quanto sarebbe difficile per Microsoft supportare la distribuzione di app .net su OSX e Linux [chiuso] Passando informazioni Meta dal comando tramite Aggrega all'evento

score 1 · Accepted Answer

Se una specifica proprietà dell'ambiente è importante per quel test, allora sì, verifica la condizione preliminare direttamente nel test. In particolare, questo è utile quando il sistema sottoposto a test esegue una sorta di transizione di stato.

Ad esempio, sto scrivendo un sistema di gestione degli account utente. Voglio testare che posso aggiungere nuovi utenti. Per verificare se un nuovo utente è stato creato, è logico assicurarsi che l'utente non sia mai esistito in precedenza. Per esempio. espresso in notazione Cucumber:

Scenario: adding a new user
  Given I have an account management system
    And no user named "Fred" exists
   When I add a user named "Fred"
   Then a user named "Fred" exists

o più xUnit-ly:

void test_addingANewUser() {
  assertNull(accounts.getUserByName("Fred"));

  accounts.createUser("Fred");

  assertNotNull(accounts.getUserByName("Fred"));
}

Penso che la verifica di queste precondizioni sia una cosa perfettamente chiara da fare, indipendentemente da di come si crea lo stato del sistema prima del test. Senza questa condizione preliminare, il test case è incompleto e dipende da qualche codice di configurazione per tutti i dettagli. Con questa precondizione, il test è più autonomo e quindi più mantenibile.