Penso che non ci sia molto di più, potresti essere "vicino" all'intera immagine (almeno l'immagine di cui sono a conoscenza), quindi ti darò una lista di parole-buzz.
-
nessun test : non usare!
-
test-last : vecchie stronzate del passato, come i dottori che non si lavano le mani oi contabili che tentano di saltare la contabilità della partita doppia. Meglio di nessun test, ma ancora non usare.
-
test-first : la cosa da fare, ma fallo bene, vedi TDD.
-
TDD : approccio formalizzato al test-first, basato sulle 3 leggi dello sviluppo guidato dai test, che ci guida attraverso un ciclo Red-Green-Refactor.
-
ATDD : applicazione del test-first sui test di accettazione. Le 3 leggi sono cambiate da "scrivi" a "scelta", in quanto di solito non vogliamo aspettare con la scrittura di ulteriori test di accettazione per i test di accettazione attuali da superare.
-
Trasformazioni Priority Premise : sequenza di trasformazioni che dovremmo tenere a mente per sapere con quali test iniziare e quali test scrivere (TDD) o selezionare / aggiungere (ATDD) successivamente.
-
3 A : Disponi, agisci, asserisci - i tre passaggi principali di un caso di test.
-
4 A : estensione di 3 A: organizzare, agire, affermare, annientare. Non dimentichiamo di ripulire.
-
BDD : mappatura dei 3 A rispetto ai buoni nomi givenArrangement, whenAction, thenAssertion , idealmente in un formato di file leggibile da umani non tecnici, come Gherkin.
-
Single-Assert-Rule : solo un'asserzione logica per caso di test. Manifestazione dell'SRP in fase di test.
-
Mocking : la sostituzione di componenti / classi / oggetti con test-doubles . Utilizzato per coprire l'interfaccia richiesta verso la cosa sostituita dalla quale dipende il componente / classe / oggetto sotto test. Utilizzato anche per accelerare i test (ad esempio un db in-memory falso sarà più veloce di un db SQL reale). Aiuta anche con il design, in particolare il disaccoppiamento, per diminuire l'immobilità e migliorare la riutilizzabilità. Ontologia: mock extends spy extends stub extends dummy estende il doppio test astratto; fake estende il doppio test astratto. Ma usa solo il mocking quando ti aiuta, ad esempio, accelera i test sostituendo le dipendenze esterne. Non prendere in giro perché puoi, prendi in giro solo quando ne hai effettivamente bisogno.
-
Test di integrazione : test dell'interazione combinata tra componenti / classi / oggetti. Attualmente il settore in cui l'industria è carente di più, in quanto sembra che nessuno sappia ancora come ottenere correttamente questa parte. Se vuoi diventare famoso, correggi questo argomento.
E infine, quali sono i test? I test sono le specifiche dei requisiti effettivi. Quello che ppl chiamava specifica dei requisiti in realtà non è una specifica dei requisiti, è un modello dei requisiti (semplificato e incompleto). Quando pubblichiamo il software, non guardiamo il codice su uno schermo e il documento dei requisiti sull'altro schermo, che lo attraversa come una lista di controllo, ma stiamo eseguendo dei test. Pertanto, i test sono la vera specifica dei requisiti.
Come per tutte le linee guida e le leggi, usa il giudizio quando non seguirle. Non vuoi dire ai tuoi clienti che le loro carte di credito sono state rubate perché prima dovevi scrivere un test per quel bug di SQL injection trovato da uno dei tuoi clienti. Ma non vuoi neanche dire ai tuoi clienti che le loro carte di credito sono state rubate perché dopo aver corretto quel bug di SQL injection non hai scritto test per verificare la correzione e cercare altri bug del genere.