Perché dovrei eseguire le specifiche rspec sulla mia app per rotaie solo in un ambiente di test, non in dev o prod?

Question

Mi è stato detto che non dovrei eseguire le mie specifiche rspec in un file rails_env diverso dal test.

Quali sono i potenziali problemi con le specifiche di produzione o sviluppo? Corro specifiche in entrambi. Di solito eseguo le specifiche in dev a meno che non stia testando qualcosa che utilizza la pipeline degli asset. Passo alla produzione per questo e trascorro 15 minuti per la pre-compilazione delle risorse. Ci sono dei vantaggi nell'utilizzare l'ambiente di test rispetto ai miei metodi attuali?

Ho cercato una risposta ma non ho spiegato perché non dovrei usare dev o prod.

Answer 1

Le suite di test in esecuzione (come rspec) in un ambiente test intendono isolare le risorse per motivi di sicurezza, in particolare l'integrità dei database. I test spesso corrompono o cancellano completamente i dati nei database.

Lo stesso vale per tutte le risorse. Utilizzando l'ambiente test è possibile tagliare e simulare le risorse, impedendo così ai test di danneggiare qualsiasi cosa.

Esistono molti motivi per utilizzare ambienti separati, ma fondamentalmente si tratta di una separazione delle risorse e, nel contesto dell'ambiente test, è possibile abilitare la convalida della propria applicazione garantendo al contempo la sicurezza delle risorse di produzione e del sistema in esecuzione.

Answer 2

Cerchiamo di essere chiari, soprattutto per nubes che possono essere lettura di questo post: RAILS_ENV=production (localmente) non è lo stesso di di prova in esecuzione "nell'ambiente production." So che tu (OP) lo sai, ma il pericolo di eseguire test nell'ambiente di produzione garantisce questo avvertimento.

Ci sono molte ragioni per solo eseguiti in test ENV, in genere relativi al trattamento dei DB:

• Rspec costruisce una 'versione' personalizzata dei dati nel DB, ed opera su quella, persistendo alcune modifiche sul disco.
• Molti test cancellano i dati esistenti, verso la fine dell'isolamento del test e rendono le cose idempotenti. Ciò potrebbe riassorbire i dati che stai utilizzando per gli edifici in prova.

altri motivi sono lungo le linee che hai ipotizzato già:

1. vostro ambiente prod non dovrebbe includere le gemme che vengono utilizzati per il test. Perché ?:
   • gemme test aggiungere più codice che potrebbe essere necessario ot lod & corsa, inutilmente, in app dal vivo
   • gemme di test relativi possono introdurre i buchi di sicurezza nella vostra applicazione di produzione.
2. alcune attività potrebbero non essere testate correttamente dopo essere state "compilate".
3. Le risorse e altri precompilatori deploy-pipe-line possono essere gestiti in modo diverso/disattivato/ecc., Al servizio del processo di test.
4. Determinate API e servizi possono essere sandboxed o stub in test/staging, ad esempio chiamate API a servizi pay-per-use, come email o report.

Le possibilità sono troppo personalizzati (per la vostra applicazione) per suggerire un best-practice ... ma, inutile dirlo, ci sono molte impostazioni 'modalità test' che possono avere bisogno di configurazione quando rails_ENV=test

Answer 3

Dovresti chiarire le tue priorità. Perché esegui le specifiche?

1. per essere sicuri, che l'ambiente xyz corre il codice a tutti o
2. per essere sicuri, che il codice fa come dovrebbe

spec

direi, la maggior parte ppl corrono per 2 ., e che dovrebbe davvero avvenire nell'ambiente di test, solo per i motivi indicati nella risposta NewAlexandrias.

Quando si desidera controllare circa 1. dopo l'implementazione, le specifiche di funzionamento mi sembrano un po 'inverosimili. Ci dovrebbero essere modi più semplici.

Quando si distribuisce, e non si è sicuri di 2. ... questa è una distribuzione prematura, qualcosa che non dovresti fare.