Dove vengono eseguiti i test

I test automatici possono in genere essere eseguiti eseguendo uno script manualmente o utilizzando un helper da un framework di test, spesso chiamato test runner, per trovare ed eseguire test. In ogni caso, potresti non volere eseguire gli script manualmente. Esistono diversi modi per eseguire i test che possono fornire feedback e in vari momenti del ciclo di vita dello sviluppo.

Script prerequisito

Di solito i progetti web hanno un file di configurazione, ovvero il file package.json, configurato da npm, pnpm, Bun o simili. Questo file di configurazione contiene le dipendenze del progetto e altre informazioni, così come gli script helper. Questi gli script helper potrebbero includere le modalità di creazione, esecuzione o test del progetto.

All'interno di package.json, dovrai aggiungere uno script denominato test che descriva come eseguire i test. Questo è importante perché, quando si utilizza npm o un modello lo strumento "test" ha un significato speciale. Questo script può puntare a un singolo file che genera un'eccezione: ad esempio node tests.js, ma ti consigliamo di utilizzarla per indirizzare a un e un esecutore di test consolidato.

Se utilizzi Vitest come runner per il test, i tuoi package.json file avrà il seguente aspetto:

{
  "name": "example-project",
  "scripts": {
    "start": "node server.js",
    "test": "vitest --run"
  }
}

L'esecuzione di npm test con questo file esegue una volta il set di test predefinito di Vitest. Nella Vitest, l'impostazione predefinita è trovare tutti i file che terminano con ".test.js" o simili ed eseguirle. In base dell'esecutore del test scelto, il comando potrebbe essere leggermente diverso.

Abbiamo scelto di utilizzare Vitest, un framework di test sempre più diffuso, esempi di questo corso. Puoi scoprire di più questa decisione in Vitest come runner di test. Tuttavia, è importante ricordare che i framework e i runner di test, anche lingue diverse, tendono ad avere un gergo comune.

Chiamata di test manuale

L'attivazione manuale dei test automatici (ad esempio, l'utilizzo di npm test nel nell'esempio precedente) possono essere pratiche mentre lavori attivamente su un codebase. Scrivere test per una funzionalità durante il suo sviluppo può aiutarti a ottenere un come dovrebbe funzionare la caratteristica, questo tocca il concetto di e lo sviluppo basato sui test (TDD).

I test runner hanno in genere un breve comando che puoi richiamare per eseguire tutti i test ed eventualmente una modalità Looker che ripete i test man mano che salvi che li rappresentano. Sono tutte opzioni utili durante lo sviluppo di una nuova funzionalità e progettato per semplificare la scrittura di una nuova caratteristica, dei suoi test o di entrambi grazie a un rapido feedback. Vitest, ad esempio, funziona in modalità Watcher per impostazione predefinita: il comando vitest controllerà le modifiche ed eseguirà nuovamente gli eventuali test rilevati. Me consigliamo di lasciarla aperta in un'altra finestra mentre scrivi i test, in modo da ricevere un feedback rapido sui test man mano che li sviluppa.

Alcuni runner ti consentono anche di contrassegnare i test come only nel codice. Se il codice include only test, solo questi verranno attivati quando li esegui, rendendo lo sviluppo di test più rapido e più facile per la risoluzione dei problemi. Anche se tutti i tuoi i test vengono completati rapidamente, utilizzando only può ridurre il carico di lavoro e rimuovere distrazione dell'esecuzione di test non correlati alla funzione o al test su cui stai lavorando.

Per i progetti di piccole dimensioni, in particolare quelli con un solo sviluppatore, puoi anche vuoi prendere l'abitudine di eseguire regolarmente l'intera suite di test del tuo codebase. Ciò è particolarmente utile se i test sono di piccole dimensioni e vengono completati rapidamente (in pochi secondi per tutti i test) in modo che tu possa verificare funzioni prima di proseguire.

Eseguire test durante l'invio o la revisione

Molti progetti scelgono di confermare il corretto funzionamento di un codebase quando deve essere unito di nuovo nel ramo main. Se non hai mai eseguito i test, ma hanno contribuito ai progetti open source in passato, parte del processo di richiesta di pull (PR) conferma che tutti i test del progetto il pass, il che significa che il tuo nuovo entusiasmante contributo non ha inciso negativamente progetto esistente.

Se esegui i test in locale, il repository online del progetto (ad esempio, GitHub o un altro servizio di hosting di codice) non sapranno che i test sono stati superati. quindi eseguire test come attività prima dell'invio chiarisce a tutti i collaboratori che funziona tutto.

GitHub, ad esempio, li definisce come "controlli dello stato" che puoi aggiungere tramite Azioni GitHub. Le azioni GitHub sono fondamentalmente un tipo di test: ogni passaggio deve riuscire (non fallire o generare un Error) affinché l'azione venga approvata. Puoi applicare Azioni a tutti i PR di un progetto, e un progetto può richiedere il superamento delle azioni prima di fornire codice. di GitHub l'azione Node.js predefinita esegue npm test come uno dei suoi passaggi.

Questo approccio ai test cerca di assicurarsi che il codebase sia sempre "verde" perché non accetta codice che non esegue correttamente i test.

Esecuzione di test nell'ambito dell'integrazione continua

Una volta accettata la PR verde, la maggior parte dei codebase esegue di nuovo i test in base del ramo main del progetto, anziché del PR precedente. Ciò potrebbe verificarsi immediatamente o regolarmente (ad esempio, ogni ora o notte). Questi i risultati vengono spesso mostrati come parte di una dashboard di integrazione continua (CI) mostra lo stato generale del progetto.

Questo passaggio della CI potrebbe sembrare ridondante, soprattutto per i progetti con codebase di piccole dimensioni: test superati durante la revisione, quindi devono essere superati quando viene applicata una modifica. Tuttavia, non è sempre così! I test potrebbero non riuscire improvvisamente, anche dopo un esito positivo producono risultati ecologici. Ecco alcuni dei motivi:

• Diverse modifiche sono state accettate "contemporaneamente", a volte nota come condizione di gara, e si influenzano a vicenda in modi impercettibili e non testati.
• I test non sono riproducibili o il test risulta "irregolari" di codice, possono passare e non riesce senza alcuna modifica al codice.
  • Questo può accadere se dipendi da sistemi esterni al tuo codebase. Per un proxy, immagina di testare Math.random() > 0.05: l'operazione non andrebbe a buon fine del 5% del tempo.
• Alcuni test sono troppo costosi o costosi da eseguire su ogni PR, ad esempio end-to-end test (ulteriori informazioni in merito nei tipi di test automatici), e possono interrompersi nel tempo senza ricevere avvisi.

Nessuno di questi problemi è impossibile da risolvere, ma vale la pena rendersi conto che i test e lo sviluppo software in generale, non sarà mai un della scienza.

Un intervallo durante il rollback

Quando i test vengono eseguiti nell'ambito dell'integrazione continua e anche quando vengono come parte di un controllo dello stato, è possibile che la build risulti "rosso" o un altro stato che indica che i test non sono andati a buon fine. Come detto in precedenza, questo può accadere per una serie di motivi, tra cui le condizioni di gara durante il test o test irregolari.

Per i progetti più piccoli, l'istinto potrebbe essere quello di considerarli come una crisi. Interrompere la riproduzione eseguire il rollback o il ripristino della modifica in questione e tornare a una buono. Questo può essere un approccio valido, ma è importante ricordare che testare (e il software in generale) è un significa un fine, non un obiettivo per trovare le regole. Il tuo obiettivo probabilmente è scrivere software, non superare tutti i test. Puoi invece eseguire il rollback in avanti seguendo la modifica che provoca un errore con un altro modifica che corregge i test non riusciti.

D'altra parte, potresti aver visto o lavorato a progetti di grandi dimensioni che esistono in uno stato perennemente interrotto. O, peggio ancora, il progetto di grandi dimensioni ha un test instabile che si rompe abbastanza spesso da causare affaticamento da sveglia per gli sviluppatori. Questo è spesso un problema esistenziale che i leader devono risolvere: test potrebbero essere disattivati perché vengono considerati "d'intralcio lo sviluppo del prodotto".

Non esiste una soluzione rapida per questo problema, ma può essere utile per acquisire maggiore sicurezza nella scrittura (miglioramento delle competenze) e di ridurre l'ambito dei test (semplificazione) in modo che gli errori possono essere identificati più facilmente. Un aumento del numero di test dei componenti o test di integrazione (ulteriori informazioni sui tipi nella sezione Tipi di test) può offrire maggiore sicurezza rispetto a un enorme test end-to-end difficile da gestire e da provare tutto in una volta sola.

Risorse

• Quali sono i vantaggi di avere costruzioni notturne

Verifica le tue conoscenze