Si dovrebbe essere in grado di accedere a un db durante i test?

I feel that tests should be able to tell you where you went wrong.

Ho capito il tuo punto di vista, ed è un principio che sono molto d'accordo. Quando apri la porta per eseguire il debug del db, abbassi l'incentivo dello sviluppatore a fare sforzi per fare test che spieghino adeguatamente il problema quando falliscono.

Per quanto corretto, penso che la tua argomentazione sia, devi consentire dei compromessi nel mondo reale. Nessun test è perfetto Se accade qualcosa al database, non correlato e non causato dal codice, il risultato del test potrebbe segnalare un problema perché ha rilevato un'anomalia, anche se i test non sono in errore. O forse i tuoi esami hanno dimenticato di coprire un caso limite.

Quando costringi i tuoi sviluppatori a fare affidamento esclusivamente sui test esistenti, il lavoro dei tuoi sviluppatori può essere corretto solo come i test stessi. Se i test contengono errori qualsiasi , gli sviluppatori non solo non saranno in grado di risolverli, ma potrebbero anche essere inviati nella direzione sbagliata, cercando un bug che pensano esistesse perché un test sbagliato loro così.

Questa è una scelta difficile. Da un lato, si vuole incentivare strongmente gli sviluppatori a fare affidamento su test automatici anziché sulla propria attitudine al debugging quando si guardano i dati.
D'altra parte, il blocco totale dell'accesso al database presuppone implicitamente che i test siano perfetti. È impossibile sapere definitivamente che i tuoi test sono perfetti. Il meglio che puoi ottenere è "non aver ancora visto un problema".

Puoi creare un ostacolo invece di un ban. Per esempio. consente solo a un sottoinsieme degli sviluppatori di accedere alle risorse (ad esempio, lead tecnici o senior). Ciò significa che i tuoi sviluppatori dovranno prima parlare con i tuoi esperti prima che possano accedere alla risorsa, incentivandoli così a non voler immediatamente eseguire il database per ogni problema minore che incontrano.
Quando sorge un problema che genuinamente richiede l'accesso al database, gli esperti saranno in grado di fornirlo. Quando si verifica un problema che non richiede l'accesso al database, sarà in grado di bloccarlo.

1. Should we write our application in a way that a developer can access the db.

Ci sono compromessi tra nessun accesso e accesso completo. Ma ancora più importante, non credo che un dev abbia bisogno di accedere al database , ma piuttosto dei dati che erano nel database. Questa è una distinzione importante da fare.

Ad esempio, puoi scaricare il contenuto del database in un file di registro quando viene rilevato un errore di test (rendi questa un'opzione configurabile in modo che accada solo quando un dev lo richiede esplicitamente).

Per essere chiari, "scaricare il contenuto del database" è una generalizzazione eccessiva. Il punto che sto cercando di fare è logg i dati rilevanti. In questo modo, i tuoi sviluppatori hanno accesso ai dati (in formato log) senza bisogno di accedere al database stesso.

2. Should developers be allowed to run tests across non-dev environments.

No. Esiste un'alternativa migliore: consentire agli sviluppatori di copiare un database da un ambiente non-dev a un ambiente di sviluppo e quindi testare ciò che vogliono.

Questo potrebbe essere complicato a causa delle regole GDPR / privacy, ma questa è una discussione diversa.

L'unico motivo per guardare un ambiente non-dev è quando si guarda a un problema specifico dell'ambiente. Richiedi ai tuoi sviluppatori di dimostrare per primi che non sono in grado di riprodurre l'errore nell'ambiente di sviluppo (con gli stessi dati) prima di consentire loro di uscire dall'ambiente di sviluppo.

I test dovrebbero essere autonomi, quindi usare i DB in memoria è un ottimo approccio. Ma questo non dovrebbe impedirti di creare una suite di test utile : se avere accesso al DB dopo un errore di test aiuta a eseguire il debug, allora assicurati che l'accesso sia possibile.

Nella maggior parte dei casi, la diagnostica della suite di test stessa dovrebbe essere adatta per eseguire il debug di un problema. Questo non dovrebbe essere solo un "test X fallito", ma "test X ha atteso dati foo, ma ha ottenuto data bar". Quale tipo di informazioni mostrare dipende dal tuo contesto. Conservare il DB dopo ogni errore di test sarebbe probabilmente eccessivo. Invece, aggiungi un'opzione al tuo runner di prova in modo che possa salvare il DB in caso di fallimento invece di abbatterlo - se uno sviluppatore vuole eseguire il debug di un problema può provare a riprodurre l'errore con quell'interruttore attivato.

Si noti che un DB in memoria non è sempre l'ideale, ad es. se il tuo DB di produzione è totalmente diverso. Ad un certo punto dovrai testare la tua configurazione di produzione. Di solito avresti test di integrazione separati che coprono questo. Un'altra opzione potrebbe essere quella di configurare il runner di test dell'unità in modo che possa connettersi a un DB esterno, ma il valore predefinito è il DB in memoria. Nota che questo può avere lo svantaggio di rendere i tuoi test più fragili.

I feel that tests should be able to tell you where you went wrong.

Come funzionerebbe?

Guarda uno pseudo-test:

// arrange
var name = "John";
var userService = SetupUserServiceWithMemoryDb();

// act
userService.AddUser(17, "John");

// assert
Assert.IsInDatabase("user", "John");

Ora quel test può dirmi che è fallito. posso dirmi che "John" non è nel database. Ma non può dirmi perché . Senza l'accesso al database, ora dovrò passare attraverso ogni parte del mio programma per scoprire perché.

Con l'accesso al database, posso almeno vedere dove devo iniziare a cercare. Forse la tabella del database contiene un "john" minuscolo perché ho dimenticato che i nomi utente vengono normalizzati in lettere minuscole. O forse ho messo "john" nel campo Id e il suo "nome" ora è 17. Il punto è che posso scoprire che è andato storto senza indovinare. Perché non c'è modo di scrivere un test per dirti cosa è andato storto. Lasciarmi scavare attraverso ogni riga del mio codice perché vuoi imporre uno standard sembra piuttosto dirompente. Perché dovrei essere bannato dall'accedere alla RAM sul mio stesso computer?

Should we write our application in a way that a developer can access the db.

Perché no? Almeno l'accesso in lettura sta sicuramente aiutando a trovare gli errori più velocemente. Non so perché l'accesso in scrittura sarebbe necessario, ma ancora ... perché no. Supponendo che non costa quasi nulla scaricare il database sul disco dopo un test fallito, provaci.

Sono assolutamente favorevole ad avere test automatici per uno standard specificato, ma è necessario farlo esplicitamente. Non limitare l'accesso a informazioni preziose perché ritieni che possa indirettamente portare a persone che seguono un determinato standard. Se vuoi quello standard, usa il modo in cui la tua azienda preferisce impostarlo e applicarlo.

Should developers be allowed to run tests across non-dev environments.

Ah ... no? Potrei mancare il contesto qui. L'intero ambiente di sviluppo in memoria è proprio quello di non doverlo permettere. Suppongo che tu abbia un ambiente che esattamente come produzione in dev. Quindi lo stesso sistema di database per esempio. Non per ogni test, ma per test di integrazione prima che qualcosa vada in diretta.

Ora, le correzioni di bug saranno certamente consentite, in qualche modo i dati devono essere riparati una volta che i bug si sono insinuati. Ma test? Non c'è modo. Ecco a cosa serve l'ambiente di test.