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.
- Questo può accadere se dipendi da sistemi esterni al tuo codebase. Per un
proxy, immagina di testare
- 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
Verifica le tue conoscenze
Qual è il nome dello script speciale che npm e programmi simili durante i test?