quello di cui intendo parlare oggi è a
un po ‘del tipo di
aspetti tecnici di un’accettazione
approccio test-driven al software
sviluppo e praticità di
costruzione automatizzata di alto livello funzionale
prova che puoi vivere con e quello
il tuo sistema sotto test può cambiare e
non compromettere la capacità di mantenere
quelle prove di corsa e di passaggio sono a
cosa complicata per avere ragione e così là
sono un numero di piccole cose diverse
ma che si sommano per farli
possibile e questo è davvero il punto focale di
il mio discorso oggi, quindi prima dovrei ricordare
per favore votare il discorso e poi
parleremo di ciò che siamo
davvero mirando a coprire qui così è
il mio modello di una pipeline di distribuzione così
hanno detto questo è una specie di uno schema
che tendo ad usare per descrivere cosa
stiamo parlando e cosa siamo
parlando di consegna continua davvero
quello che stiamo cercando di fare è che lo siamo
cercando di ottenere un alto livello di fiducia
che i cambiamenti che abbiamo appena fatto sono
probabilmente è buono, non possiamo mai provarlo
che i cambiamenti sono buoni e quindi cosa noi
il lavoro è che lavorerai per falsificare il nostro
cambia con test automatici che vogliamo
eseguire un sacco e un sacco di test automatici e
se uno di questi test fallisce , vogliamo farlo
scartare il candidato al rilascio e spostarsi
a per cercare di risolvere il problema che
abbiamo introdotto quindi questo è tutto
queste cose sono davvero forme di
test di accettazione e ma davvero il mio obiettivo
è qui sono su questi test di accettazione
e questi sono come definiti come
parte del metodo di consegna continua
come valutare il software dal
prospettiva di un utente esterno di
il sistema in modo che sia un buon posto per
iniziare stiamo cercando di rispondere al
domanda fa ciò che fanno gli utenti
vorrebbe che facesse la prima fase di
prova il tipo di stadio TDD dell’unità
fase di test è di affermare se
il software fa quello che gli sviluppatori
penso che dovrebbe essere fatto e questo è
davvero molto importante davvero davvero
prezioso e ci dà un feedback veloce ma
oltre a questo vogliamo anche sapere che
fa quello che gli utenti volevano oggi vogliamo
essere in grado di usare queste cose come un tipo
di definizione automatica di fatto avremmo
piace essere in grado di scrivere uno di questi
cose queste specifiche per il
comportarsi
il sistema e poi vorremmo essere in grado
lavorare finché non ci adattiamo, abbiamo finito e
quando passa quel test lo sappiamo
abbiamo finito definisce l’ambito di
lo sviluppo le persone il pezzo di lavoro
che stiamo cercando di farlo non è solo
sul test questo è uno strumento per il design
questo è uno strumento per lo sviluppo che aiuta
il processo di sviluppo che vogliamo
asserire che il codice funziona
produzione come ambienti non lo è
abbastanza buono solo per eseguire test che dicono
questo piccolo pezzo funziona da solo non sono i miei
Scommetto che se sei abbastanza stupido da
lascia che ti lasci libero nel tuo
organizzazione potrei rompere il tuo software
più rapidamente cambiando il suo
configurazione quindi potrei cambiando
il codice sorgente e ancora molto spesso noi
non preoccuparti di testare questo tipo di
cambiamenti voglio valutare questi cambiamenti
Voglio implementare il software in
produzione come ambienti voi
valutare che la configurazione del
sistema funziona anche il dispiegamento di
il sistema funziona anche con le dipendenze
che tutto il nostro software si basa su
anche sul posto di lavoro e noi vogliamo
testare la configurazione implementata di
intero sistema e vogliamo fornire
feedback tempestivo se ci vuole tre
anni per imparare se il cambiamento è così
abbiamo appena fatto è buono è uno spreco del nostro
il tempo è quello che non è il
feedback prezioso più breve è il tempo
tra fare il cambiamento e l’ apprendimento
se il cambiamento è buono, meglio è
quindi il più che guida bene
i comportamenti in generale ho consigliato il mirare
per feedback entro un’ora
non importa la scala del tecnico
problema e puoi farlo con alcuni
tecnica sorprendentemente complicata
problemi se si applica l’ingenuità e
riflettere su come ottimizzare per
un breve feedback fa il ciclo del genere
test di accettazione di cui sto parlando
circa è probabilmente ha un numero di
diversi nomi inchiostrati nel contesto di
consegna continua ne abbiamo parlato
come test di accettazione ma è anche
essendo indicato come accettazione
lo sviluppo basato sui test è stato spesso
parlato nel contesto del comportamento
guidato comportamento di sviluppo guidato
lo sviluppo in realtà è venuto da qualche parte
altro era lo sviluppo guidato dal comportamento
originariamente un’idea che è stata progettata per
prova e permettici di insegnare di più al TDD
in modo efficace e raggiungere l’alto valore di
TDD prima, ma spesso viene visto il BDD
ha detto che le idee certamente disegnano a
linea molto bene con le idee di
test di sviluppo è solo lo scopo di
il test che è diverso davvero a
specifica per esempio in realtà il mio
descrizione preferita di ciò che siamo
provare a fare è quest’ultimo eseguibile
le specifiche non sono davvero
test stiamo cercando di definire eseguibile
specifiche per il comportamento del nostro
sistema Ho un amico che ha un cliente
questa è una compagnia aerea e stanno usando
questo approccio e quando quando un membro
dei telefoni pubblici fino al supporto
organizzazione presso questa compagnia aerea e parlare con
il personale di supporto il
informazioni che sono le persone di supporto
utilizzando sullo schermo sono l’eseguibile
specifiche per il comportamento del
sistema descrivono il comportamento del
sistema questo è molto molto forte
affermazione che la versione del sistema di
il sistema che è in produzione è passato
questo test ha soddisfatto questo
specificare la persona al telefono
sa che è così che funziona il sistema
perché la specifica dice che è
come funziona il sistema è quello che sono
parlare di
quindi mi piace pensare ad una buona accettazione
test è una specifica eseguibile per
il comportamento del sistema e questo è un
buon modello mentale per entrare e
pensando a queste cose un altro
il modello mentale che penso affettuosamente è questo
uno e questa è l’idea del software
sviluppo come una serie di feedback
loop all’esterno abbiamo il cruciale
circuito di feedback che cerchiamo di ottimizzare
la consegna continua ha un’idea da ottenere
quell’idea nelle mani dei nostri utenti
e capire cosa ne ricavo gli utenti di
idea e lavoriamo per far sì che il
ciclo di feedback dall’avere un’idea e
ottenere quell’idea nelle mani del nostro
utenti tanto brevi quanto efficienti come
possibile all’interno è che il TDD
feedback loop il test guidato
ciclo di feedback sullo sviluppo che stiamo per fare
scrivere un test che vedremo fallire
scriveremo del codice da fare
passiamo a rifare così siamo
andando a impegnarci, andremo avanti
e questo sta accadendo in pochi secondi o
pochi minuti di solito e poi dentro
tra questo è questo ciclo di feedback e questo
è quello a cui mi riferisco parlando
di
questo riguarda l’ uscita da questi eseguibili
specifiche con il sistema di comportamento
stiamo andando a esaminare il comportamento di
il nostro software dal punto di vista di un
utente esterno del nostro sistema in
produzione come ambienti e
valutalo e comprendi l’impatto di
i nostri cambiamenti, quindi cosa è il
problema perché sei qui e perché lo sono
Io parlare con te di questo sembra
come una buona idea, giusto perché non lo facciamo?
fai questo perché è così difficile il
il problema è che ciò che tende ad accadere
le persone hanno cercato di fare questo tipo
di cose per molto tempo e cosa tende
Succedere è che quando il sistema sotto
prova le modifiche rompe i test che è
un problema difficile da risolvere e quello che siamo
davvero parlando da a
il punto di vista dell’informatica è a
problema di accoppiamento dei test in questo in
questo esempio è troppo stretto per
il sistema in prova quindi uno di
le nostre strategie sono di provare a ridurlo
accoppiamento per lavorare in un modo in cui testiamo
i casi sono vagamente accoppiati con rispetto
al sistema in prova può essere
complesso lo sviluppatore che vogliamo essere in grado
a Siamo idealmente, se abbiamo intenzione di usare
queste cose come una parte fondamentale di
il nostro processo di sviluppo che vogliamo essere
in grado di avere decine di migliaia di questi
i casi di test sono in grado di svilupparli molto
rapidamente e li eseguo molto rapidamente a
affermare il comportamento dei nostri sistemi e
quindi vogliamo essere in grado di crearli
le cose in modo rapido ed efficiente non lo facciamo
Devo passare ore e ore e ore
e giorni cercando di venire con ogni
caso di test individuale quindi un sacco di questo è
circa è di un problema di progettazione e
stiamo andando a parlare di questo in qualche
dettaglio attraverso il resto del discorso
intanto penso alla storia di questo
è una specie di test funzionale fuckshit
pieno di cattivi esempi, sono io
in particolare amo la registrazione e la riproduzione dell’interfaccia utente
sistemi penso che siano proprio così
fragile così difficile da mantenere e io
penso che questi siano anti- schemi, penso
utilizzando i dati di produzione nei nostri sistemi
un anti-modello che voglio essere in grado di
test voglio valutare il comportamento di
il mio sistema proprio non voglio solo
gettare casualmente i dati e vedere cosa
succede e quindi penso ci siano molte cose
di cattivi modelli che sono
e comunemente praticato e noi che andiamo parlare
un po ‘di più su quelle cose per a
parte fondamentale di questo mandato da a
il punto di vista del processo è una questione di chi
possiede il test, penso che sia, è così
importante riconoscere e ed e in a
parte vitale di stabilire questi
loop di feedback efficaci che il
gli sviluppatori sono nel ciclo il
Gli sviluppatori sono le persone che renderanno
cambia le modifiche che interromperanno i test
quindi sono le persone che hanno bisogno
di essere responsabile per fare il test
passare quando ciò accade, dobbiamo chiudere
il ciclo di feedback di cui abbiamo bisogno per davvero
rallentare gli sviluppatori se lo sono
fare cambiamenti che stanno rompendo cose
dobbiamo rallentarli per ottenere il
risolvere e dobbiamo mantenere il
il software funziona se queste cose sono genuine
ci sono specifiche eseguibili di
le specifiche del file eseguibile per
il comportamento del sistema allora quando a
lo sviluppatore introduce un cambiamento
rompe un test che significa questo
il sistema non soddisfa più il suo
requisiti che non soddisfa più
il suo contratto di comportamento o crimine e
è dove vorremmo arrivare a quello
ciò che è il modo in cui vorremmo
lavorare così quest’ultima volta che sono stato
lavorando nello sviluppo di software come
sviluppatore e un tecnico per oltre
35 anni e quest’ultimo non l’ho mai fatto
mai visto questo lavoro penso che questo sia uno
delle idee più tossiche nel nostro settore
l’idea di avere una squadra di QA separata
scrivere test automatizzati divorziati da
il team di sviluppo è ciò che accade
che il team di controllo qualità scriva alcuni test e
poi li fanno lavorare e poi il
il team di sviluppo si muove e lo spezzano
fanno cambiamenti che rompono i test
e poi per il resto della loro esistenza
il team di controllo qualità spende i loro sforzi per provare
correre dietro e cercare di recuperare e
cercando di rattoppare le cose insieme per fare
il test passa e non fanno quasi mai
che non ti dà un buon feedback noi
bisogno di chiudere il ciclo che dobbiamo fare
sviluppatori responsabili dei test
chiunque può scrivere il test questi sono
queste sono le specifiche chi ha il
l’ idea più chiara di quali siano i requisiti
è dalla prospettiva di un esterno
utente del sistema possono scrivere il
prova ma non appena inizia il test
gli sviluppatori esecutori sono responsabili per
e loro sono quelli che faranno
i cambiamenti
per farlo passare se introducono a
cambiamento che fa fallire uno dei
definizioni di consegna continua è
lavorando in un modo che ha il software
sempre in uno stato rilasciabile questo è un
parte fondamentale di tutto il resto del mio discorso
si concentra davvero su questo e questo è un
elenco di proprietà a sinistra che penso
come proprietà di buoni test di accettazione a
molte delle cose che sono andando mettere prima
si è basata su un’esperienza che ho avuto
lavorando in modo abbastanza complicato
ambiente complesso che costruisce uno dei
i più alti scambi di prestazioni nel
mondo
abbiamo costruito l’intero sistema aziendale
e usa questi tipi di strategia
quindi voglio che tu te lo tenga a mente
non stiamo parlando di semplici banali
sistemi di cui stiamo parlando in grande
complicata classe imprenditoriale del mondo reale
sistemi con caratteristiche prestazionali
che ti spaventi mi hanno spaventato quando
ci stavamo lavorando così voglio parlare
sai che voglio parlare un po ‘
in quel contesto e questo è un po ‘
informato da quell’apprendimento penso che sia
giusto dire che quell’organizzazione che
è stato chiamato owl max un problema con
probabilmente di livello mondiale è automatizzato
test abbiamo avuto decine di migliaia di
queste cose corrono e ci entreremo
più tardi quindi ecco qui
proprietà quindi penso che dovremmo essere
cercando di concentrare i nostri test su ciò che noi
voglio affermare non come è il
sistema sui test realizza che noi
voglio essere in grado di volere che il test a
essere isolati l’ uno dall’altro vorremmo
essere in grado di eseguire molti di questi e se
vogliamo ottenere un rapido riscontro
probabilmente vorrai eseguirli in parallelo
e quindi hanno tagliato non possiamo permetterci
loro di incontrarsi l’un l’altro che vogliamo
essere ripetibili ci piacerebbe essere
in grado di eseguire lo stesso test più e più volte
di nuovo e diventa affidabile coerente
risultati al fine di fare questo uno dei
cose che veramente aiutano e ci aiutano
qualcuno scrive il test e ci aiuta
capire cosa significano i test nel
il contesto del problema giusto è quello che usiamo
la lingua del dominio del problema sono
introdurrò l’idea di usare
lingue specifiche del dominio per esprimere il nostro
ha bisogno di questo tipo di test automatici
e vogliamo essere in grado di testare qualsiasi
cambiamento vogliamo essere in grado di valutare
il nostro software in quasi ogni contesto
possiamo pensare a e in questo e
capire l’impatto di ciò quando noi
parlare di alcuni casi in cui il
più che recuperare ma alcuni avremmo anche
piace essere queste cose per essere efficiente
non possiamo permetterci di trascorrere giorni o settimane
o anche ore in attesa di un risultato noi
voglio il feedback più veloce che possiamo
ottenere se siamo in grado di ottenere un feedback in meno di un
ora
quello è un diverso che è un
livello di feedback in grado di cambiare se dopo
un’ora possiamo essere in una posizione tale
non c’è più lavoro da fare prima di noi
spingiamo un cambiamento verso la produzione
comunque complesso un sistema che è un
livello di feedback che cambia il gioco, quindi facciamolo
iniziare e passiamo attraverso l’elenco così
ci concentreremo su cosa non come
ecco un lui è uno schema del sistema
che stavo parlando dei dettagli di
questo non molto non importa molto
molto ho intenzione di parlare di questo
bit l’API fix per quelli di voi
non provengono dal settore finanziario e
non so quali correzioni non importa il
il modello mentale per questo è immaginarlo
quando sto parlando di un’API REST è
non è un’API REST , è diverso ma
semanticamente potrebbe anche essere nel
contesto di questo discorso va bene così andiamo
immagina di avere un sistema come questo
ha un numero di diverse comunità di
utenti un numero di canali di
interazione attraverso il sistema e lo faremmo
piace essere in grado di valutare il software
attraverso tutti questi canali così
tipicamente se stiamo per scrivere test
contro un sistema come quello è questo
noi introdurremmo un sacco di
casi di test che descrivono come
sai cosa vogliamo testare
e com’è che stiamo andando
interagire con il sistema sotto test ora
il problema con questo è se un cambiamento
succede in uno di questi canali di
comunicazioni e invalida un intero
un sacco di questi casi di test che parlano
attraverso quel canale l’unica cosa che
possiamo fare per risolvere questo è andare a ciascuno di
questi singoli casi di test e sistemati
quei casi di test che saranno
complicato perché lo saranno
bit complicati di codice perché sono
sono preoccupati per due diversi
cose se tu se ti interessa profondamente
idee di design e separazione come
separazione delle preoccupazioni ci stiamo fondendo
riguarda la fusione di ciò che è
stiamo cercando di esprimere come è
che stiamo interagendo con il sistema
e il test e questo aggiunge sempre un po ‘
più complessità quindi cosa facciamo in a
problema come questo nel software in
l’ingegneria del software ci piace
introdotto un livello di riferimento indiretto e
alzato il livello di astrazione così qui
lui è un mucchio di canali che
che rappresenta diverse comunità di
utenti e forniamo un driver di dispositivo se
ti piace che stub un canale e
astrazione che rappresenta quel concetto
nella terminologia che loro
soddisfa i bisogni dei casi di test ora se
questo sistema cambia e invalida il
ipotesi nei casi di test abbiamo solo
avere un posto dove sistemarlo perché noi
perché tutte queste cose passano attraverso
questo unico canale di comunicazione che possiamo
sistemalo in un posto, non ti preoccupare, lo sono
entrerò nel dettaglio di ciò che io
significa per quello che passiamo attraverso quello che tu
tendono a trovare come te mentre lo fai
il tipo di astrazione è ciò che trovi
che ora hai anche questo segnaposto
per le infrastrutture che hai, non lo sei
stai solo parlando di casi di test
parlando di alcune infrastrutture di test
ci sono alcune idee di design di supporto
e strumenti e strutture che consentono
questo tipo di pensare questo tipo di
astrazione e parleremo di più
su queste cose nel tempo queste
piccoli blob verdi che abbiamo
diversi tipi che aiuteranno
noi raggiungiamo questo livello di astrazione e
mantenerlo così l’idea è quella
abbiamo questa infrastruttura di prova
questo è condiviso tra i casi di test
puoi puoi andare a toccarli
le cose che puoi risolvere risolvono i problemi in uno
posto
Vogliamo vogliamo vogliamo vogliamo pensare
su queste cose in termini di sai
il comportamento del sistema quindi eccoti tu
sai, ecco una lista di cose e solo per
ti confondo che alcune di queste cose sono
sbagliato non penso che ogni test dovrebbe
controlla le condizioni di partenza a
ottimo punto di partenza per i test unitari
ed è un cattivo punto di partenza per questo
tipo di test funzionale perché
di solito si avvia il sistema
caro ci piacerebbe essere in grado di forse
ripartire all’avvio del sistema e
forse sicuramente se è un multiutente
sistema vorremmo essere in grado di avere un sacco
di differenza non ci piace avere un
avviare il sistema in una sola volta e poi avere un sacco
di diversi test eseguiti contro lo stesso
sistema che ne avrà alcuni
implicazioni a sé stante ma ci piacerebbe
essere in grado di separare queste due decisioni
a volte vogliamo voler iniziare
il sistema per un test case ma
a volte non è così che vorremmo essere
in grado di avere la scelta che vogliamo il test
essere una prova generale per la versione di produzione
vorremmo per il momento una versione
il candidato arriva al punto di
dispiegamento in produzione
questo è un non-evento perché questa versione
candidato è già stato schierato
utilizzando questa versione della distribuzione
strumenti e questa configurazione del
infrastruttura molte volte durante un
viaggio e convalida attraverso il
pipeline di implementazione se facciamo questo tipo
di cose ciò che questo porta è che dà
noi questa bella opportunità per il futuro
accelerare il ciclo di feedback dei test
parallelizzando le cose e condividendo il
avviare in testa come come ho detto
passiamo alla prossima nel nostro
elenca così vorremmo che i nostri test fossero
isolato da altri test ora un avvertimento
qui ho passato gran parte della mia carriera
lavorando in una sorta di sistemi multiutente di
una forma o l’ altra
se stai scrivendo software per un
persona individuale a cui è dedicato
quelli che probabilmente probabilmente stanno ottenendo
questi giorni sono sempre più insoliti, ma se
stai scrivendo un software come questo
di questi questi consigli non lo fanno
abbastanza in forma, ma per il resto di noi questo
queste idee sono solo un po ‘di lavoro
pensaci, iniziamo a pensare al test
l’isolamento III pensa che qualsiasi forma di
test in qualsiasi dominio sta valutando
qualcosa in circostanze controllate
e quindi la parte di controllo è importante
l’isolamento è importante nel
contesti a più livelli che vogliamo
essere in grado di isolare il sistema sotto test
vogliamo essere in grado di provare solo
la roba che è il confine del nostro
responsabilità che vogliamo essere in grado di
isolare i casi di test l’uno dall’altro come me
detto prima vorremmo essere in grado di correre
molti di questi in parallelo e non hanno
li incontrano l’un l’ altro e ci piacerebbe
essere in grado di isolare i casi di test da
loro stessi in modo che possiamo eseguire lo stesso test
caso più e più volte penso che lo sia
utile pensare in questi termini se tu
non fare questo ciò che tende ad accadere è
quando inizi a salire di livello e ad arrivare
cicli di feedback più rapidi si trova tutto
tipi di conflitti di condivisione delle risorse e
test si incontrano l’un l’altro quando si
prova ad occhi paralleli e quello comincia a
rendere più difficile accelerare
questo è un attributo molto comune delle persone
che non hanno pensato all’isolamento
prima del tempo le mie cose hanno smesso di funzionare
quindi iniziamo a pensare
isolando l’ isolamento e eccone uno
esempio di quello di cui sto parlando
questo è ciò che tende ad essere molto comune in
grandi imprese immaginiamo che noi
stanno lavorando sul sistema B e sul sistema B
uno di questi sistemi che ce n’è dell’altro
sistema a monte e un altro sistema
a valle è nel mezzo e cosa
cosa è spesso raccomandato in questi tipi
di esempi è necessario testare il
tutto in due parti devi
valutare tutte queste cose insieme
ora c’è un problema con quello se io
voglio essere in grado di specificare con precisione il
dichiari che il mio sistema è attivo per
essere in grado di testarlo e sto solo facendo
che tramite un altro sistema non posso non posso
sii preciso abbastanza ci sono un’intera zattera
di diversi tipi di scenari che io
non può simulare passando attraverso un
primo sistema esterno , se voglio essere
in grado di simulare il sistema mandandomi
spazzatura o il canale di comunicazione di
non riesco a far cadere i sistemi C
simulare quelli in cui non riesco a testare il mio sistema
quelli in quei tipi di scenari, se lo sono
testare il tutto per finire così io
non ho davvero avuto un ottimo modo chiaro
di ottenere il sistema sotto test in
lo stato che voglio che sia in peggio
di quello se sto lavorando al sistema B che sono
non
essere un esperto di sistema a e sistema C
e così il grado in cui posso esercitare
controllo anche se ci sono cose che io
potrei fare da lì che stai andando
essere limitato in base alla mia comprensione
dobbiamo dividere in compartimenti i nostri
capire in modo che le cose possano andare bene
nelle nostre teste quindi questo è un problema
significa che il sistema sul test non lo è
nelle città non controllabili
dichiari quando noi quando facciamo questo tipo di
test, quindi penso che questo sia un
anti-modello
questo non può essere la base per un solido
base per test di accettazione efficaci
quello che ci piacerebbe davvero è invece
qualcosa di più come questo ci piacerebbe essere
in grado di avere i nostri casi di test il più vicino possibile
il sistema in prova come possiamo e poi
catturare l’ output alcuni verificare che siamo
ottenere quello che ci aspettiamo vorremmo essere
in grado di simulare tutti questi diversi
tipi di scenari che vorremmo essere in grado
per iniettare schifo dati e e e e
simulare queste comunicazioni conosciute
fallimenti qualunque cosa ci interessi
circa ci piacerebbe essere in grado di prendere
controllo ci piacerebbe essere in grado di voi
pensare a tipo di sonde putting
attorno al sistema sotto quello sotto test
il che significa che dobbiamo essere molto chiari
su dove i confini per il nostro
il sistema ora è il problema è è quello
quando le organizzazioni dicono che cosa faremmo
come se tu fossi questo è quello che sono
sono preoccupati di queste bollette
preoccuparsi di quelle interfacce che cambiano
e questa è una vera preoccupazione è un it’s a
vero problema una di queste strategie per
questo di cui Mary ha parlato nel
il keynote talk qui è assicurato
quelle interfacce sono sciolte sulla base di
protocolli accoppiati liberi in modo da poter usare a
sistema di messaggistica e che ti dà un
un po ‘ dimenarsi
ma è comunque un problema vero
cosa facciamo per verificare quelle interfacce
Penso che quello che ci piacerebbe davvero è
che vorremmo una serie di test ciascuno
focalizzato sui singoli sistemi come noi
appena descritto se lo facciamo se siamo ancora
facendo questo dal punto di vista di
sistema B anche se quello che vorremmo sapere
del sistema esterno a è soddisfa
le nostre aspettative sul suo protocollo di
comunicazione con noi e quando prendiamo
concentrare il numero di test che noi
bisogno di correre è in realtà abbastanza
più così possiamo definire alcuni test che
diciamo che l’interfaccia è sempre la stessa e
forse anche noi possiamo arrivare al punto di dare
quei test per team a e possono correre
i loro test come parte del loro continuo
infrastruttura di integrazione e se loro
fare un cambiamento che invalida il nostro
assunzione della loro interfaccia che conoscono
che ora abbiamo un’integrazione
problema questo ci dà la possibilità
fare tutto il nostro accurato approfondimento
test dettagliati per ottenere il sistema
sotto test a precisamente lo stato
che vorremmo che tu sia in, ma anche
qualche difesa delle interfacce tra
noi ho usato questa strategia molte volte in
girare incluso con terzo esterno
feste e questo è stato abbastanza per me così
lontano non ho trovato non ho trovato un
problema dove questo è quello che è
questo è causato da una difficoltà
questa è la strategia così come ho detto prima
nel complesso sto lavorando da
l’assunzione di sistemi multi-utente noi
voglio essere in grado di isolare i casi di test che noi
vogliamo che vogliamo essere in grado di correre
molti di questi test e cosa avremmo davvero
come ti piace essere in grado di avviare il
sistema in una sola volta ed eseguono quindi eseguire
un sacco di questi test, al fine di farlo
dobbiamo isolare il test da uno
un altro non possiamo permettercelo di condividere
risorse che non vogliamo che siano
scrivendo per conoscere gli stessi file o
gli stessi set di dati o gli stessi record
nei database o qualunque cosa possa essere
e questo è un po ‘complicato quando pensiamo
su un intero sistema che siamo
valutando una delle buone strategie per
fare se stiamo parlando di un multi-utente
il sistema è qualcosa che chiamo
aliasing funzionale in modo da utilizzare naturale
confini nel sistema per isolare
prova l’ uno dall’altro questo è un altro
uno di quei tipi di tipo 8020
progetto in realtà probabilmente più simile a
95 5 ma per la stragrande maggioranza dei test
casi è possibile utilizzare questo tipo di
isolamento funzionale e ottieni no
problemi e di cosa sto parlando
Immaginiamo che stavamo testando Amazon così
se stessimo testando Amazon ogni singolo
test creerebbe un nuovo account e a
nuovo libro o prodotto e poi se lo fossimo
testando eBay creiamo un nuovo account e
una nuova asta per ogni test case e se
stavamo testando github ne creiamo uno nuovo
account e un nuovo repository per ogni
caso di test si ottiene una sorta di strano
profilo nel sistema in prova perché
ne hai un sacco
repository o molti libri creati
e molti utenti hanno creato ma è a
modo davvero bello di isolare i sistemi
davvero semplicemente dai test case davvero
semplicemente l’uno dall’altro, se vuoi
fallo allora, lo sai che c’è
un altro passo ci piace avere questi
risultati ripetibili ci piacerebbe essere in grado
eseguire lo stesso test case più e più volte
ancora e così se corro lo stesso lo stesso
test due volte dovrei ottenere lo stesso risultato
Ecco un esempio di formaggio quindi ecco qui
qualcuno sta cercando di provare e scrivere un test
caso per comprare il mio libro, quindi abbiamo un negozio
e stiamo creando un libro nel taglio
portata del caso di test , quindi stiamo andando
per effettuare un ordine per il libro e poi
affermeremo che l’ordine è stato
posto ora il pezzo che mi preoccupa
circa qui è un po ‘ così creare un
prenota se eseguo questo test case e io solo
leggilo letteralmente e finisci da qualche parte
memorizzare alcune informazioni nel sistema
e il test che rappresenta quel libro
così la prossima volta che verrò
eseguire quel caso di test sono ora in una
stato diverso ora quando eseguo quel test
caso il libro esiste già l’ultima volta
appena creato ora esiste già forse
un altro al test ha cambiato il
affermare che quel libro è in forse è
esaurito o qualcosa del genere, perché
di un test che è stato eseguito e lo siamo
andando a prendere una collisione che otterremo
un problema un test fiocchi vibrazione qui così
questa è una strategia molto semplice ora
invece di farlo in questo modo quello che facciamo
è quello nel caso di test nel
esempio di un caso di test nostro
infrastruttura ricorda il nostro test
infrastruttura nostra infrastruttura
Scheduie leggere questo come una richiesta piuttosto
di un’istruzione dice ok, lo faresti
come un libro si chiama continuo
consegna, ma in realtà non importa che
è una consegna continua , ti conosco
non mi interessa davvero , quindi lo farò
un nome diverso e lo mapperò
al nome che vuoi nello scope
di questo test eseguito ma all’interno del sistema
sotto test sarà diverso
e non ti interessa così la prossima volta
correrò, otterrò un nome diverso e
ora ho l’ isolamento del test così giusto
usando l’aliasing riempi la sua funzione
facilità per tutti questi funzionali
le entità ci consente di eseguire questi test
casi in parallelo e separati da uno
un altro è banalmente semplice
ma è davvero molto efficace quindi a
buon punto di partenza utilizzare funzionale
le entità di isolamento li alias sempre
mantieni sempre il nome in qualche modo
così che i nomi meridionali saranno
unico per ogni esecuzione di testo quindi tu
può eseguire lo stesso test più e più volte
ancora e non ne avrai nessuna
problemi quindi vorremmo che il nostro test fosse
ripetibile vogliamo essere in grado di utilizzare
test come meccanismo di falsificazione
ci piacerebbe essere in grado di non appena a
il test fallisce , stiamo per scartare il
rilasciare il candidato, quindi vogliamo essere in grado
per fidarmi delle prove, direi che il
test di eventuali test automatizzati di qualsiasi forma
sono in realtà solo preziosi quando sono
in caso contrario è possibile avere un numero di test pari a
ti piace e se ti passano tutti
non so che il test potrebbe essere spazzatura
potrebbe perdere la chiave cosa sono
solo veramente trasmettendo informazioni come
hai una probabilità che forse lo sei
va bene
se hai un sacco di casi di test
stanno passando ma tu conosci veramente solo il
stato del tuo sistema quando un test fallisce
e ti dice che i tuoi sistemi non vanno bene
abbastanza, quindi abbiamo bisogno che il nostro test sia
affidabile non possiamo permetterci i test a fiocchi
non possiamo non poterci permettere i test?
a volte lavoro e altre volte no
ciò significa che dobbiamo controllare
di nuovo essere molto preciso e molto specifico
riguardo al controllo del nostro sistema, facciamolo
immagina di avere un sistema come
questo abbiamo ottenuto un sistema sotto
test e abbiamo qualche sistema esterno
di cui stiamo parlando, stavamo parlando
prima di dove tipo di questi end-to-end
prove che non ci piace molto e
immaginiamo che abbiamo imparato a scrivere
software non da Visual Basic per
manichini ma per qualcos’altro e e
non abbiamo stretto un paio di quelli
due cose abbiamo un’interfaccia locale
tra qui che un’astrazione B di
la comunicazione tra questo sistema
e questo sistema in qualche modo ulteriormente
oltre a ciò abbiamo la comunicazione
canale tra questi due sistemi si
sapere che il resto API o il
prese e qualunque cosa sia il
meccanismo per la comunicazione tra
questi due sistemi quello che vorremmo essere
in grado di fare nell’ambito di un test come
abbiamo detto è che vorremmo scaricare il
sistema esterno non vogliamo davvero
per essere lì è solo confusione e questo
non ci dà un controllo sufficiente
non ci dà il non in realtà
dacci la ripetibilità che non ci dà
la capacità di ottenere veramente il sistema
sotto test allo stato che eravamo
nel fare e tu che vogliamo che sia
dentro e valutarlo in controllo
circostanze quindi cosa possiamo fare allora
attraverso la configurazione possiamo usare il
stessa tecnologia di comunicazione del mondo reale
ma possiamo possiamo fingere di poter mozzare
fuori quei pezzi di comunicazione esterna
sono scritti di nuovo ricordano questi
queste sonde che stiamo mettendo in giro
il nostro sistema ogni punto di esterno
comunicazione vogliamo fingere che vogliamo
di collegare aa stub aaaa falsa versione
del sistema esterno in modo che possiamo
input falsi e raccogliere uscite e fare
asserzioni su ciò che tende ad accadere
è che stiamo facendo quindi ecco che
Ritrova di nuovo lui è il pubblico
interfaccia al nostro sistema e lui è il
ambito del nostro sistema sotto test che abbiamo
la nostra infrastruttura di test alcuni casi di test
ciò che è veramente bello per questi stub è
che vogliamo inserirli nel nostro test
infrastrutture sono distribuite
parte della nostra infrastruttura di test avremmo
piace essere in grado di esprimere idee nel nostro
casi di test che dicono che mi aspetto questo
risultato vorrei il sistema esterno
per fornire questo ingresso e vorremmo
fai tutto questo da attraverso di esso da a
prova in modo astratto e nascondi
quella complessità attraverso qualche canale di pipistrelli
di comunicazione tra il test
infrastruttura e sono gli stub di test
Ti ho guidato nella direzione
di questo già penso davvero che sia così
cruciale utilizzando il linguaggio del
problema del dominio, quindi aiutaci a risolvere molto
di questi problemi in particolare
ci dà il giusto livello di astrazione
essere in grado di esprimere queste idee in a
soluzione senza soluzione di continuità che ci permette di definire
queste specifiche eseguibili senza
descrivendo come funziona il sistema in questo modo
ci aiuta anche a creare questi casi di test
molto rapidamente ci permette di leggere e
capisco lo scopo del nostro test che ho
un cliente lavoro come consulente di consulenza
gente su come fare alcune di queste cose
e consegna continua cose in
generale
Ho un cliente nei Paesi Bassi che
hanno un tipo di funzionalità automatizzata
test abbastanza seriamente per diversi
anni hanno un corpo molto grande di
test funzionali automatizzati e loro
parole che sono orribili che sono
complicato complicato che ci vuole
la persona che ha scritto il test mezzo an
ora 60 minuti per capire cosa
il test sta facendo in modo che abbiano tutto
questi test non sanno cosa sia
la copertura è che non sanno cosa sono
affermando di non sapere se lo è
buono o cattivo anche così la capacità di
capire cosa sta asserendo molto un test
chiaramente essere molto precisi è importante
pensando a queste cose come
specifiche con il comportamento del
sistema ci fornisce con questo livello giusto
dell’astrazione dell’ascrizione e possiamo
inizia a progettare le lingue che ci consentono
per esprimere quelle idee ecco un esempio
Spero che tu possa leggere questo, quindi questo è un
esempio reale dal sistema che ero
parlare di questo è nel
sfera sfera del trading finanziario e
in questo caso stiamo selezionando un accordo
biglietto che è un marchio e il
strumento rappresenta un mercato in cui
puoi scambiare un ordine
un tipo particolare che stiamo verificando per vedere
quale sia il feedback da quell’ordine e
stiamo piazzando un altro ordine e lo siamo
cercando il feedback qui ecco
un altro caso di test questo sta andando
attraverso l’API fix che ho menzionato
prima e stiamo sostituendo un maestro
per entrare nel mercato
in uno stato noto che una istruzione
sta creando il mercato a partire da
o Avani che definisce alcuni utenti per commerciare
in quel mercato e mettendo un mucchio
dei prezzi sul mercato che il
i test successivi possono essere scambiati in tal modo
ricorda quello che ho detto sulla facilità con
scrivendo questi test e ottenendo il
sistema sotto test nello stato che
vorremmo che tu sia molto veloce e
quindi facciamo altre interazioni come
Ho detto prima di ogni caso di test
ha iniziato a mettere in atto il sistema
in una condizione che si desidera
essere in modo che stiamo creando uno strumento
e alcuni utenti che saranno in grado di farlo
commercio e quel genere di cose da ottenere
il sistema per testare questo è il prossimo
livello in basso in modo che questi è questo questo
è questo il test in
per una struttura che i casi di test
condividere e sono e stanno parlando di questo è
un esempio di ordine di posto e puoi vedere
una delle proprietà di questo
è che stiamo usando un sacco di optional
parametri quindi se non mi interessa cosa
ordina che io sia il dettaglio dell’ordine
che sto piazzando posso fornire un posto
ordine con credo che nessun parametro che posso
solo dire di ordine del posto e si farà
uno per me che funzionerà se non lo faccio
cura il dettaglio dell’ordine se voglio
per essere precisi sull’ordine che posso
specificare ogni attributo dell’ordine
ecco un’altra versione di questo che è
per il dispetto no, non ho il
altra versione quindi per altre API
può essere più complicato in realtà cosa
Ho appena mostrate si era un po ‘un
iterazione di dove siamo e noi
realizzato nel tempo che anche a quello
livello non eravamo abbastanza divorziati
da come funzionava il sistema che abbiamo
ho trovato cose qui troppo specifiche
quindi stavamo parlando del trading
interfaccia utente e la fix API e noi
capito che non c’era bisogno di fare
che potremmo astrarre ulteriormente, abbiamo finito
con casi di test come questo questo singolo
il caso di test esprime un desiderio reale
comportamento del sistema che vorremmo essere
in grado di effettuare un ordine in un particolare
mercato di un tipo particolare e lo faremmo
piacerebbe vedere un rapporto di esecuzione a
risposta per il comportamento di quell’ordine
questo caso di test funziona sull’API di correzione
il sito web pubblico e l’API pubblica
che le persone potrebbero usare ma potrebbero usare
scrivi il loro, ma bene questo è uno
il caso di test esprime questo requisito e
può essere soddisfatta in tre diversi
colloca lo stesso cliente di cui stavo parlando
circa prima nei Paesi Bassi sta usando
questa tecnica lì stanno riscrivendo a
sistema legacy e quindi migrazione verso
un approccio microservizi che sono
riscrivendo i loro test di accettazione in questo
tipo di forma e ne hanno due
versioni differenti la versione precedente di
il sistema e la nuova versione di
sistema possono eseguire lo stesso
specifiche e affermano che ottengono
lo stesso comportamento su entrambi i sistemi
è piuttosto potente e dimostra
accoppiamento veramente libero tra il test
caso e il sistema sotto test è possibile
ora immagina che il sistema sotto test sia
in grado di cambiare
abbastanza drammaticamente senza impatto
la natura di questo test non lo fa
molta importanza la natura dell’ordine esso
non importa se stai piazzando
ordine significa compilare alcuni dettagli in a
forma o cliccando su un grafico no
importa questo ha ancora senso
vorremmo essere in grado di testare qualsiasi cambiamento
come parte del nostro processo di sviluppo noi
non voglio solo testare le cose facili
o semplicemente testare i percorsi felici che vogliamo
testare tutti i comportamenti del nostro sistema
quindi sto solo tirando fuori alcuni
diversi casi Lmax
dove ho lavorato abbiamo testato ogni attributo
del sistema abbiamo testato le prestazioni
caratteristiche che vorremmo fare
uccidere selettivamente i bit del sistema e
controlla che quel sistema non ne abbia perso
dati tutti questi tipi di cose ma
Mi concentrerò solo su un paio di
cose così ovvie che tende a
inciampare è tempo è uno di quelli
dipendenze che tendono a entrare nel nostro
molto e credo che ci siano
due strategie per affrontare il tempo
nei test automatici il primo è se
al tuo sistema non interessa molto
tempo ignorarlo
escludere qualsiasi confronto di campi temporali
e basta ignorare quei confronti che
funziona se il tuo sistema non ha importanza
circa il tempo molto l’altro approccio
è prendere il controllo del tempo, quindi cosa faccio
significa per quello
quindi ecco il primo approccio che ignora
tempo il bello vantaggio che questo
l’approccio è che è davvero semplice
solo quando confronti i dati
tra due diverse implicazioni di
il sistema vi si ignorare tutti
il tempo di campi il guaio è che esso
può mancare errori e impedisce il tuo
testare alcuni interessanti e complessi
scenari se il sistema si preoccupa
tempo ed è qui che entra così
test prendendo il controllo del tempo è
molto flessibile è estremamente potente
ti consente di eseguire scenari di lunga durata
puoi farlo in brevi periodi di tempo
simula tutti i tipi di diverso
interazioni con il tempo e vedere le cose dentro
diverso il lato negativo è leggermente
più complesso in termini di
infrastruttura e il setup quindi facciamolo
basta approfondire questo argomento in un altro po ‘
dettaglio ancora mi scuso per il
esempio un po ‘ approssimativo, diciamo
che qualcuno vuole prendere in prestito il mio libro
dalla biblioteca e stanno andando a
asserire che il libro è in ritardo non lo è
in ritardo e poi stanno andando a
il viaggio nel tempo qui è il bit che siamo
interessato a provare e
viaggiare avanti una settimana e poi
affermeranno che il libro
non sono ancora in ritardo, ottengono un tempo
viaggio avanti di quattro settimane
e ora stanno andando ad affermare che il
il libro è ormai scaduto, quindi chiaramente è il
bit di viaggio nel tempo che sono i
bit interessanti in questo scenario così
ecco il nostro sistema sul test e qui
la nostra infrastruttura di test che lo circonda
e in genere in questo tipo di scenario
se abbiamo qualche nozione di tempo in
il nostro sistema da qualche parte ci sarà
qualcosa che assomiglia vagamente a questo
nel codice del sistema che stiamo per fare
avere un quarto di tempo per ottenere il tempo
equivalente in qualunque lingua o
infrastruttura che stai usando di nuovo noi
risolvere questo tipo di problema con
introducendo un livello di indirezione così
invece di chiamare direttamente nel
sistema abbiamo messo il nostro orologio nel modo
così invece di chiedere al sistema per il
tempismo e chiedere un orologio per il tempo e
ogni volta che il sistema chiede il tempo
chiede un orologio ora possiamo iniziare a fare scherzi
con esso
quindi potremmo introdurre un orologio come questo
potremmo avere un orologio che per impostazione predefinita
sta parlando con l’impiegato del sistema e lui
va e prende tempo da
sistema ma possiamo anche imbrogliare e noi
potrebbe impostare il tempo dall’esterno e
restituisce sempre quel tempo qualunque esso sia
è possibile collegarlo al nostro test
infrastruttura in modo che potessimo fare il
istruzioni per il viaggio nel tempo e dire ok così
ci piacerebbe fare questo ci piacerebbe tempo
viaggeremo per interpretare cosa
questo significa in termini di tempo e poi
stiamo andando a impostare il tempo nel
sistema e il test come ho detto questo
ci permette di valutare a lungo andare
scenari nel settore finanziario dove
questi esempi erano alcuni degli esempi
presi da noi spesso hanno una specie di tre
ciclo giorno a volte cicli più lunghi e
non vuoi eseguire un test per tre
giorni per scoprire se funziona, tranne uno
delle cose leggermente divertenti a Lmax
abbiamo parlato con quindici o
venti terzi come parte del nostro
tutto il sistema aziendale che conosci
altre organizzazioni commerciali che si stanno liberando
ospita tutti questi tipi di luoghi e
ogni volta c’era una luce del giorno
risparmi per cambiare all’orologio uno o
altri di questi terzi si sarebbero rotti
e non l’abbiamo mai fatto perché abbiamo provato
abbiamo testato che abbiamo testato la luce del giorno
scenario di cambio di risparmio
nel nostro codice con con questo con questo
approccio al viaggio nel tempo quindi se vogliamo fare
questi tipi di questi tipi di diverso
questi diversi tipi di test noi
probabilmente vogliono iniziare probabilmente
avere alcune caratteristiche diverse
ricorda quello che ho detto all’inizio
sala per la maggior parte dei test che vorremmo
essere in grado di avviare il sistema in una sola volta
e poi eseguire un sacco di test
contro di esso per condividere al costo di
avviare il sistema ma non lo è
andando a lavorare per alcuni di questi test se
stai viaggiando nel tempo che non sei tu
non può essere un viaggio nel tempo in una direzione
e un altro tempo di test viaggiando in
un’altra direzione e un’altra prova no
volendo viaggiare nel tempo presso il
stesso tempo che farà casino
quindi in nessun caso probabilmente ne vorrai uno
versione dedicata nel sistema per
quei test di viaggio nel tempo in modo da poter taggare
quello con quello che abbiamo fatto è stato quello che abbiamo taggato
i test quindi abbiamo fatto test di viaggio nel tempo
e sono ora test assegnati che faremmo
guarda quei tag e li assegna in
due diversi host differenti che abbiamo avuto
prove di test distruttivi che erano
distruggendo parti della nostra infrastruttura o
bit del nostro codice per vedere come il nostro sistema
si alzò di nuovo e probabilmente non lo faresti
voglio condividere quegli ambienti
con prove giornaliere o regolari
test di performance o qualcosa di simile
e poi abbiamo fatto dei test da cui dipendeva
pezzi specifici di hardware e quindi noi
potrebbe andare a cercare gli host che avevano
quel po ‘di hardware e allocare il
le prove per loro qui è un bel po ‘
animazione quindi il ragazzo che ha scritto i test
allocatore questa è una versione abbastanza grezza
le versioni moderne sono molto più grandi e
questo libro era più complesso di quando era lui
stava sviluppando il sistema il test
alligatore e ha fatto questa visualizzazione
per capire cosa sta succedendo qui
è il test parallelo questo è quello che abbiamo
una versione del sistema e un intero
molti host test in esecuzione diversa
casi di test contro questi qui abbiamo
ho preso alcuni di quei test distruttivi
lì che ogni test ha la sua versione
del sistema e può tipo di uccidere
in modo diverso al sistema e valutare
cosa sta succedendo e qui abbiamo un
un sacco di viaggi nel tempo li mette di nuovo alla prova
ha una sua versione del sistema e
sta eseguendo quei test contro questo
versione del sistema e prendendo il controllo
di tempo in quel contesto
vorremmo che il nostro test fosse efficiente noi
voglio essere in grado di eseguire decine di migliaia
di questi test stavo parlando con a
mio collega eccetto che abbiamo lavorato
nel luogo in momenti diversi da El
Max ieri e ha detto che quando io
left del max avevano circa 15.000 di
questi test di accettazione stanno dando
risultati in circa 40 minuti quando se ne andò
che è un anno fa penso che loro
aveva trentamila di questi test
dare risultati in circa 30 minuti è stato
avrebbero aumentato l’hardware e
parallelizzato un po ‘di più ho detto così
puoi eseguire decine di migliaia di questi
test e questo è ciò che vogliamo essere in grado
per arrivare a ottenere questi feedback rapidi
cicli ecco un esempio di one one way
di guardare all’efficienza se lo sei
testare se il tuo ambiente di produzione
sembra questo e il tipico
interazione attraverso l’ ambiente
sembra che questo allora volete che il vostro
ambiente per essere come la produzione
non deve essere una produzione clone di esso
deve rappresentare gli attributi chiave di
il sistema quindi forse il tuo test
l’ambiente sembra così forse è un
un po ‘più complicato di così
un feedback più veloce, ma sta andando a
assomiglia a qualcosa di simile a qualcuno dei tuoi
le interazioni hanno un particolare insolito
un po ‘di hardware o qualcosa del genere
e alcune interazioni assomigliano a questo
forse il tuo ambiente di test è simile
questo ciò che si sta cercando di stabilire in
qui vogliamo essere in grado di eseguire il tuo
software in scenari realistici in
produzione come ambienti in modo che tu possa
valutare la distribuzione il
configurazione l’interazione di tutti
i diversi pezzi e solo il
comportamento dei bit del codice sorgente che
abbiamo scritto quando stiamo scrivendo queste questi
questi casi di test astratti di alto livello in
il nostro linguaggio specifico per il dominio non lo facciamo
voglio valere la pena di preoccuparsi del duro
roba informatica che non vogliamo assolutamente
preoccuparsi di come è il sistema
fornire i comportamenti che vogliamo solo
essere in grado di esprimere le idee del
comportamenti ma oltre quello che non facciamo
voglio essere preoccupante ancora peggio di no
davvero preoccupante per davvero complicato
cose come la concorrenza così dal
prospettiva di ogni passo nel nostro
linguaggio specifico del dominio che vogliamo
essere sincrono vogliamo che sia un
singolo passo sono completamente d’accordo con cosa
Maria ha detto nella nota dominante sul
importanza di
progettazione software asincrona, ma questo è
un posto dove vogliamo noi sincronicità
non sarà in grado di fare un passo nel nostro test
caso completo e valido e
ripetibile e quindi fare il prossimo passo
quindi se stai cercando un se lo sei
lavorando in un sistema asincrono e
vuoi falsificare questo all’interno del tuo dominio
lingua specifica di nuovo hai questo
strato infrastrutturale che ti dà un
posto per farlo, ecco un esempio
questo è questo è il livello DSL questo è
lo strato sotto i casi di test, quindi abbiamo
questa è la cosa condivisa per il posizionamento
ordini immaginiamo che stiamo per inviare
un messaggio di ordine di posto asincrono
stiamo per passare i parametri e
allora aspetteremo un
conferma o esito negativo in un timeout quindi noi
può mangiare sembrare sincrono dal
prospettiva dei casi di test ma è
in realtà asincrono sotto il cofano noi
può nascondere abbastanza piuttosto complesso
interazioni e comportamenti in questo modo
all’interno dello strato di astrazione che a
DSL ci presenta e puoi farlo come te
fare questo altri di coloro po ‘di verde
BLOB nell’infrastruttura che
tende ad andare tendenzialmente a costruire il tuo
proprio modello di dominio piccolo ti aiuta
costruisci e cresca alcune di queste idee
condividere il contesto tra i diversi passaggi in
il caso di test quindi penso di più
i miei sistemi anche-anche molto asincroni
sistemi è vero dire che c’è
quasi sempre un evento naturale conclusivo
a qualsiasi interazione se non c’è forse
dovrebbero essere forse vale la pena guardare
al design del messaggio nel tuo
sistema però se davvero davvero
davvero non riesco a trovare un evento conclusivo
quindi un approccio molto peggiore, ma ancora
un po ‘accettabile è che puoi fare a
meccanismo di polling e time-out per andare e
sembra così facile come è arrivato nel
database come ora andrò e tornare
non guardare mai in pochi secondi nel modo giusto
nel database si passa spostati su quello
tipo di cosa non dovresti mai fare
è questo che vedo questo per tutto il tempo che vado
nei clienti e parlare di aiuto con
la loro strategia di test e il loro codice è
disseminato di dichiarazioni di peso nel
nei loro casi di test questo è simile
crack crack cocaina piede per
testare questo è un anti pan completo è
andando a rendere il tuo software i tuoi test
più lento il migliore
caso è che i test stanno per essere
lento perché ogni volta che sei
andando ad aspettare forse tornato in a
microsecondo non hai dovuto aspettarti
avrei potuto risparmiare quel tempo di attesa peggio
di quello che per lo più accade però lo è
che finisci per introdurre un intero
diverse condizioni di gara che hai
hai appena spostato il gioco e inizi
giocare a tutti i giochi stupidi dalla melodia
i diversi pesi in modo da ottenere
tu eviti le condizioni di gara che sei
mai andando a farlo arrivare al reale
problema che eliminerai ti libererai di
questo e inizia a fare questo genere di cose
invece se fai tutte quelle cose
il prossimo passo nella consegna continua
diventa facile i punti in cui il tuo
il ciclo di feedback inizia a rallentare e tu
bisogno di scalare fino a ottenere un feedback più veloce
di nuovo diventa semplice, ecco la nostra
repository di artefatti abbiamo ottenuto un rilascio
candidato che finisce lì dentro dal nostro
mettere in scena un artefatto dispiegabile
qualunque cosa potrebbe essere la nostra accettazione
l’ambiente di test quando è gratis è
andando a scegliere il più nuovo di quelli
distribuirlo ad un allegato accettazione condivisa
ambiente di test che verrà generato
un sacco di host di test per eseguire tutti
questi diversi casi di test ed è
andando a valutare quel candidato al rilascio
e restituirà i risultati
e tagga il tag in cui si trova il candidato al rilascio
il repository di risorse con lo stato
e questo diventa semplice quando hai finito
queste cose se hai uno stato condiviso
un sacco di bianco condizioni di fusione di
quello che abbiamo avuto tutte queste cose
attenuare la tua capacità di farlo
scala quindi sono un po ‘nel wrap-up
la modalità ora, quindi facciamo abbastanza rapidamente noi
attraverso il riassunto di questo quindi non usare
un sistema di registrazione e riproduzione che sono
veleno non registrare indietro non solo usare
dati di produzione è al massimo è a
esempio del nostro comportamento probabilmente le cose
che fara ‘saltare il tuo software
Sarò nella tua produzione a gestirti
vuoi simulare quelle cose che vuoi
pensare a tutti i casi imbarazzanti che tu
voglio simulare i fallimenti non solo
scaricare i dati di produzione nel test
o è come arrampicarsi
e il montaggio con uno zaino pieno di
rocce
hai appena camminato con questo
questo è un peso
dei dati per tutto il tempo non si assumono
che l’acquisto di prodotti di prova al largo del
scaffale e il consiglio che ti danno
sta per portare a un buon test
strategia la mia esperienza di molti di quelli
le cose sono che non portano a molto
buona strategia di test che devi essere
molto specifico hai bisogno di pensare molto
chiaramente su ciò che vuoi e io
argomenterebbe dal mio punto di vista come a
proponente di consegna continua il
direttiva principale
in questo tipo di approccio all’automazione
test è ciò che vuoi è veloce
feedback che è più importante di
qualsiasi cosa preferirei buttare via un test
ha impiegato troppo tempo per correre poi rallentare il
il ciclo di feedback non ha un separato
test e team di QA penso che i test
a test separati e specialisti QA
sono estremamente preziosi in una squadra ma
dovrebbero lavorare in collaborazione
intimamente con i team di sviluppo
collaborazione a grana fine no
costruire mini cascate dove il
team di sviluppo che lavora fino alla fine
e consegna le cose ai due QA
squadra anche se sono seduti insieme
vuoi fare una valutazione a grana fine
del software fino in fondo
non lasciare che ogni test in esso app in
l’applicazione a meno che la tua applicazione
è accecantemente veloce per iniziare a farlo
ripartire il costo non include i sistemi
al di fuori dell’ambito del tuo sistema essere molto
specifico su quali sono i confini di
il tuo sistema è e prova per quelli
frontiere e non mettere bianco insanguinato
dichiarazioni nei tuoi test sperando che ciò avvenga
risolverà il problema non sarà solo
rendere le tue prove più raffinate e difficili
capire e rallentare quindi non voglio
finire su un downer
quindi scusami, ci stiamo provando
per fare foto e ho finito di correre così
Non ho intenzione di andare avanti con questi
ti assicuri che gli sviluppatori possiedano il
test in modo che completino il feedback
prova il ciclo cosa no come usare la DSL
pensa all’eseguibile dei tester
specifiche che effettuano test di accettazione
parte della definizione di mantenere mantenuto
i test sono isolati l’ uno dall’altro
usando i trucchi di cui ho parlato
qui tieni i tuoi test ripetibili
non sarà in grado di eseguire lo stesso test
e ancora e ottenere gli stessi risultati
ogni volta usa il linguaggio di
il dominio del problema prova davvero il DSL
è più facile di quanto sembri a poco
evolvere queste cose molto rapidamente
fare stub sistemi esterni per definire il
limiti del test del sistema
ambienti di produzione luce provano
configurazione di distribuzione e il
comportamento del tuo sistema
le istruzioni appaiono sincrone al
livello di ciascuna delle dichiarazioni del caso di test
e prova per ogni test di modifica ogni
cambia nel tuo sistema e finalmente fai
preoccupati per le prestazioni del tuo
i test sono preoccupanti per il ciclo di feedback
preoccuparsi se il test richiede ore
è troppo lento se ci vogliono minuti
puoi farcela in pochi secondi
davvero potrebbe prendere prendere prova di prova
le prestazioni sul serio puoi impararlo
la stessa cosa in modo più efficiente se puoi
faccio con che ho fatto grazie per
il tuo tempo ho leggermente finito di correre
[Applausi]
un po ‘del tipo di
aspetti tecnici di un’accettazione
approccio test-driven al software
sviluppo e praticità di
costruzione automatizzata di alto livello funzionale
prova che puoi vivere con e quello
il tuo sistema sotto test può cambiare e
non compromettere la capacità di mantenere
quelle prove di corsa e di passaggio sono a
cosa complicata per avere ragione e così là
sono un numero di piccole cose diverse
ma che si sommano per farli
possibile e questo è davvero il punto focale di
il mio discorso oggi, quindi prima dovrei ricordare
per favore votare il discorso e poi
parleremo di ciò che siamo
davvero mirando a coprire qui così è
il mio modello di una pipeline di distribuzione così
hanno detto questo è una specie di uno schema
che tendo ad usare per descrivere cosa
stiamo parlando e cosa siamo
parlando di consegna continua davvero
quello che stiamo cercando di fare è che lo siamo
cercando di ottenere un alto livello di fiducia
che i cambiamenti che abbiamo appena fatto sono
probabilmente è buono, non possiamo mai provarlo
che i cambiamenti sono buoni e quindi cosa noi
il lavoro è che lavorerai per falsificare il nostro
cambia con test automatici che vogliamo
eseguire un sacco e un sacco di test automatici e
se uno di questi test fallisce , vogliamo farlo
scartare il candidato al rilascio e spostarsi
a per cercare di risolvere il problema che
abbiamo introdotto quindi questo è tutto
queste cose sono davvero forme di
test di accettazione e ma davvero il mio obiettivo
è qui sono su questi test di accettazione
e questi sono come definiti come
parte del metodo di consegna continua
come valutare il software dal
prospettiva di un utente esterno di
il sistema in modo che sia un buon posto per
iniziare stiamo cercando di rispondere al
domanda fa ciò che fanno gli utenti
vorrebbe che facesse la prima fase di
prova il tipo di stadio TDD dell’unità
fase di test è di affermare se
il software fa quello che gli sviluppatori
penso che dovrebbe essere fatto e questo è
davvero molto importante davvero davvero
prezioso e ci dà un feedback veloce ma
oltre a questo vogliamo anche sapere che
fa quello che gli utenti volevano oggi vogliamo
essere in grado di usare queste cose come un tipo
di definizione automatica di fatto avremmo
piace essere in grado di scrivere uno di questi
cose queste specifiche per il
comportarsi
il sistema e poi vorremmo essere in grado
lavorare finché non ci adattiamo, abbiamo finito e
quando passa quel test lo sappiamo
abbiamo finito definisce l’ambito di
lo sviluppo le persone il pezzo di lavoro
che stiamo cercando di farlo non è solo
sul test questo è uno strumento per il design
questo è uno strumento per lo sviluppo che aiuta
il processo di sviluppo che vogliamo
asserire che il codice funziona
produzione come ambienti non lo è
abbastanza buono solo per eseguire test che dicono
questo piccolo pezzo funziona da solo non sono i miei
Scommetto che se sei abbastanza stupido da
lascia che ti lasci libero nel tuo
organizzazione potrei rompere il tuo software
più rapidamente cambiando il suo
configurazione quindi potrei cambiando
il codice sorgente e ancora molto spesso noi
non preoccuparti di testare questo tipo di
cambiamenti voglio valutare questi cambiamenti
Voglio implementare il software in
produzione come ambienti voi
valutare che la configurazione del
sistema funziona anche il dispiegamento di
il sistema funziona anche con le dipendenze
che tutto il nostro software si basa su
anche sul posto di lavoro e noi vogliamo
testare la configurazione implementata di
intero sistema e vogliamo fornire
feedback tempestivo se ci vuole tre
anni per imparare se il cambiamento è così
abbiamo appena fatto è buono è uno spreco del nostro
il tempo è quello che non è il
feedback prezioso più breve è il tempo
tra fare il cambiamento e l’ apprendimento
se il cambiamento è buono, meglio è
quindi il più che guida bene
i comportamenti in generale ho consigliato il mirare
per feedback entro un’ora
non importa la scala del tecnico
problema e puoi farlo con alcuni
tecnica sorprendentemente complicata
problemi se si applica l’ingenuità e
riflettere su come ottimizzare per
un breve feedback fa il ciclo del genere
test di accettazione di cui sto parlando
circa è probabilmente ha un numero di
diversi nomi inchiostrati nel contesto di
consegna continua ne abbiamo parlato
come test di accettazione ma è anche
essendo indicato come accettazione
lo sviluppo basato sui test è stato spesso
parlato nel contesto del comportamento
guidato comportamento di sviluppo guidato
lo sviluppo in realtà è venuto da qualche parte
altro era lo sviluppo guidato dal comportamento
originariamente un’idea che è stata progettata per
prova e permettici di insegnare di più al TDD
in modo efficace e raggiungere l’alto valore di
TDD prima, ma spesso viene visto il BDD
ha detto che le idee certamente disegnano a
linea molto bene con le idee di
test di sviluppo è solo lo scopo di
il test che è diverso davvero a
specifica per esempio in realtà il mio
descrizione preferita di ciò che siamo
provare a fare è quest’ultimo eseguibile
le specifiche non sono davvero
test stiamo cercando di definire eseguibile
specifiche per il comportamento del nostro
sistema Ho un amico che ha un cliente
questa è una compagnia aerea e stanno usando
questo approccio e quando quando un membro
dei telefoni pubblici fino al supporto
organizzazione presso questa compagnia aerea e parlare con
il personale di supporto il
informazioni che sono le persone di supporto
utilizzando sullo schermo sono l’eseguibile
specifiche per il comportamento del
sistema descrivono il comportamento del
sistema questo è molto molto forte
affermazione che la versione del sistema di
il sistema che è in produzione è passato
questo test ha soddisfatto questo
specificare la persona al telefono
sa che è così che funziona il sistema
perché la specifica dice che è
come funziona il sistema è quello che sono
parlare di
quindi mi piace pensare ad una buona accettazione
test è una specifica eseguibile per
il comportamento del sistema e questo è un
buon modello mentale per entrare e
pensando a queste cose un altro
il modello mentale che penso affettuosamente è questo
uno e questa è l’idea del software
sviluppo come una serie di feedback
loop all’esterno abbiamo il cruciale
circuito di feedback che cerchiamo di ottimizzare
la consegna continua ha un’idea da ottenere
quell’idea nelle mani dei nostri utenti
e capire cosa ne ricavo gli utenti di
idea e lavoriamo per far sì che il
ciclo di feedback dall’avere un’idea e
ottenere quell’idea nelle mani del nostro
utenti tanto brevi quanto efficienti come
possibile all’interno è che il TDD
feedback loop il test guidato
ciclo di feedback sullo sviluppo che stiamo per fare
scrivere un test che vedremo fallire
scriveremo del codice da fare
passiamo a rifare così siamo
andando a impegnarci, andremo avanti
e questo sta accadendo in pochi secondi o
pochi minuti di solito e poi dentro
tra questo è questo ciclo di feedback e questo
è quello a cui mi riferisco parlando
di
questo riguarda l’ uscita da questi eseguibili
specifiche con il sistema di comportamento
stiamo andando a esaminare il comportamento di
il nostro software dal punto di vista di un
utente esterno del nostro sistema in
produzione come ambienti e
valutalo e comprendi l’impatto di
i nostri cambiamenti, quindi cosa è il
problema perché sei qui e perché lo sono
Io parlare con te di questo sembra
come una buona idea, giusto perché non lo facciamo?
fai questo perché è così difficile il
il problema è che ciò che tende ad accadere
le persone hanno cercato di fare questo tipo
di cose per molto tempo e cosa tende
Succedere è che quando il sistema sotto
prova le modifiche rompe i test che è
un problema difficile da risolvere e quello che siamo
davvero parlando da a
il punto di vista dell’informatica è a
problema di accoppiamento dei test in questo in
questo esempio è troppo stretto per
il sistema in prova quindi uno di
le nostre strategie sono di provare a ridurlo
accoppiamento per lavorare in un modo in cui testiamo
i casi sono vagamente accoppiati con rispetto
al sistema in prova può essere
complesso lo sviluppatore che vogliamo essere in grado
a Siamo idealmente, se abbiamo intenzione di usare
queste cose come una parte fondamentale di
il nostro processo di sviluppo che vogliamo essere
in grado di avere decine di migliaia di questi
i casi di test sono in grado di svilupparli molto
rapidamente e li eseguo molto rapidamente a
affermare il comportamento dei nostri sistemi e
quindi vogliamo essere in grado di crearli
le cose in modo rapido ed efficiente non lo facciamo
Devo passare ore e ore e ore
e giorni cercando di venire con ogni
caso di test individuale quindi un sacco di questo è
circa è di un problema di progettazione e
stiamo andando a parlare di questo in qualche
dettaglio attraverso il resto del discorso
intanto penso alla storia di questo
è una specie di test funzionale fuckshit
pieno di cattivi esempi, sono io
in particolare amo la registrazione e la riproduzione dell’interfaccia utente
sistemi penso che siano proprio così
fragile così difficile da mantenere e io
penso che questi siano anti- schemi, penso
utilizzando i dati di produzione nei nostri sistemi
un anti-modello che voglio essere in grado di
test voglio valutare il comportamento di
il mio sistema proprio non voglio solo
gettare casualmente i dati e vedere cosa
succede e quindi penso ci siano molte cose
di cattivi modelli che sono
e comunemente praticato e noi che andiamo parlare
un po ‘di più su quelle cose per a
parte fondamentale di questo mandato da a
il punto di vista del processo è una questione di chi
possiede il test, penso che sia, è così
importante riconoscere e ed e in a
parte vitale di stabilire questi
loop di feedback efficaci che il
gli sviluppatori sono nel ciclo il
Gli sviluppatori sono le persone che renderanno
cambia le modifiche che interromperanno i test
quindi sono le persone che hanno bisogno
di essere responsabile per fare il test
passare quando ciò accade, dobbiamo chiudere
il ciclo di feedback di cui abbiamo bisogno per davvero
rallentare gli sviluppatori se lo sono
fare cambiamenti che stanno rompendo cose
dobbiamo rallentarli per ottenere il
risolvere e dobbiamo mantenere il
il software funziona se queste cose sono genuine
ci sono specifiche eseguibili di
le specifiche del file eseguibile per
il comportamento del sistema allora quando a
lo sviluppatore introduce un cambiamento
rompe un test che significa questo
il sistema non soddisfa più il suo
requisiti che non soddisfa più
il suo contratto di comportamento o crimine e
è dove vorremmo arrivare a quello
ciò che è il modo in cui vorremmo
lavorare così quest’ultima volta che sono stato
lavorando nello sviluppo di software come
sviluppatore e un tecnico per oltre
35 anni e quest’ultimo non l’ho mai fatto
mai visto questo lavoro penso che questo sia uno
delle idee più tossiche nel nostro settore
l’idea di avere una squadra di QA separata
scrivere test automatizzati divorziati da
il team di sviluppo è ciò che accade
che il team di controllo qualità scriva alcuni test e
poi li fanno lavorare e poi il
il team di sviluppo si muove e lo spezzano
fanno cambiamenti che rompono i test
e poi per il resto della loro esistenza
il team di controllo qualità spende i loro sforzi per provare
correre dietro e cercare di recuperare e
cercando di rattoppare le cose insieme per fare
il test passa e non fanno quasi mai
che non ti dà un buon feedback noi
bisogno di chiudere il ciclo che dobbiamo fare
sviluppatori responsabili dei test
chiunque può scrivere il test questi sono
queste sono le specifiche chi ha il
l’ idea più chiara di quali siano i requisiti
è dalla prospettiva di un esterno
utente del sistema possono scrivere il
prova ma non appena inizia il test
gli sviluppatori esecutori sono responsabili per
e loro sono quelli che faranno
i cambiamenti
per farlo passare se introducono a
cambiamento che fa fallire uno dei
definizioni di consegna continua è
lavorando in un modo che ha il software
sempre in uno stato rilasciabile questo è un
parte fondamentale di tutto il resto del mio discorso
si concentra davvero su questo e questo è un
elenco di proprietà a sinistra che penso
come proprietà di buoni test di accettazione a
molte delle cose che sono andando mettere prima
si è basata su un’esperienza che ho avuto
lavorando in modo abbastanza complicato
ambiente complesso che costruisce uno dei
i più alti scambi di prestazioni nel
mondo
abbiamo costruito l’intero sistema aziendale
e usa questi tipi di strategia
quindi voglio che tu te lo tenga a mente
non stiamo parlando di semplici banali
sistemi di cui stiamo parlando in grande
complicata classe imprenditoriale del mondo reale
sistemi con caratteristiche prestazionali
che ti spaventi mi hanno spaventato quando
ci stavamo lavorando così voglio parlare
sai che voglio parlare un po ‘
in quel contesto e questo è un po ‘
informato da quell’apprendimento penso che sia
giusto dire che quell’organizzazione che
è stato chiamato owl max un problema con
probabilmente di livello mondiale è automatizzato
test abbiamo avuto decine di migliaia di
queste cose corrono e ci entreremo
più tardi quindi ecco qui
proprietà quindi penso che dovremmo essere
cercando di concentrare i nostri test su ciò che noi
voglio affermare non come è il
sistema sui test realizza che noi
voglio essere in grado di volere che il test a
essere isolati l’ uno dall’altro vorremmo
essere in grado di eseguire molti di questi e se
vogliamo ottenere un rapido riscontro
probabilmente vorrai eseguirli in parallelo
e quindi hanno tagliato non possiamo permetterci
loro di incontrarsi l’un l’altro che vogliamo
essere ripetibili ci piacerebbe essere
in grado di eseguire lo stesso test più e più volte
di nuovo e diventa affidabile coerente
risultati al fine di fare questo uno dei
cose che veramente aiutano e ci aiutano
qualcuno scrive il test e ci aiuta
capire cosa significano i test nel
il contesto del problema giusto è quello che usiamo
la lingua del dominio del problema sono
introdurrò l’idea di usare
lingue specifiche del dominio per esprimere il nostro
ha bisogno di questo tipo di test automatici
e vogliamo essere in grado di testare qualsiasi
cambiamento vogliamo essere in grado di valutare
il nostro software in quasi ogni contesto
possiamo pensare a e in questo e
capire l’impatto di ciò quando noi
parlare di alcuni casi in cui il
più che recuperare ma alcuni avremmo anche
piace essere queste cose per essere efficiente
non possiamo permetterci di trascorrere giorni o settimane
o anche ore in attesa di un risultato noi
voglio il feedback più veloce che possiamo
ottenere se siamo in grado di ottenere un feedback in meno di un
ora
quello è un diverso che è un
livello di feedback in grado di cambiare se dopo
un’ora possiamo essere in una posizione tale
non c’è più lavoro da fare prima di noi
spingiamo un cambiamento verso la produzione
comunque complesso un sistema che è un
livello di feedback che cambia il gioco, quindi facciamolo
iniziare e passiamo attraverso l’elenco così
ci concentreremo su cosa non come
ecco un lui è uno schema del sistema
che stavo parlando dei dettagli di
questo non molto non importa molto
molto ho intenzione di parlare di questo
bit l’API fix per quelli di voi
non provengono dal settore finanziario e
non so quali correzioni non importa il
il modello mentale per questo è immaginarlo
quando sto parlando di un’API REST è
non è un’API REST , è diverso ma
semanticamente potrebbe anche essere nel
contesto di questo discorso va bene così andiamo
immagina di avere un sistema come questo
ha un numero di diverse comunità di
utenti un numero di canali di
interazione attraverso il sistema e lo faremmo
piace essere in grado di valutare il software
attraverso tutti questi canali così
tipicamente se stiamo per scrivere test
contro un sistema come quello è questo
noi introdurremmo un sacco di
casi di test che descrivono come
sai cosa vogliamo testare
e com’è che stiamo andando
interagire con il sistema sotto test ora
il problema con questo è se un cambiamento
succede in uno di questi canali di
comunicazioni e invalida un intero
un sacco di questi casi di test che parlano
attraverso quel canale l’unica cosa che
possiamo fare per risolvere questo è andare a ciascuno di
questi singoli casi di test e sistemati
quei casi di test che saranno
complicato perché lo saranno
bit complicati di codice perché sono
sono preoccupati per due diversi
cose se tu se ti interessa profondamente
idee di design e separazione come
separazione delle preoccupazioni ci stiamo fondendo
riguarda la fusione di ciò che è
stiamo cercando di esprimere come è
che stiamo interagendo con il sistema
e il test e questo aggiunge sempre un po ‘
più complessità quindi cosa facciamo in a
problema come questo nel software in
l’ingegneria del software ci piace
introdotto un livello di riferimento indiretto e
alzato il livello di astrazione così qui
lui è un mucchio di canali che
che rappresenta diverse comunità di
utenti e forniamo un driver di dispositivo se
ti piace che stub un canale e
astrazione che rappresenta quel concetto
nella terminologia che loro
soddisfa i bisogni dei casi di test ora se
questo sistema cambia e invalida il
ipotesi nei casi di test abbiamo solo
avere un posto dove sistemarlo perché noi
perché tutte queste cose passano attraverso
questo unico canale di comunicazione che possiamo
sistemalo in un posto, non ti preoccupare, lo sono
entrerò nel dettaglio di ciò che io
significa per quello che passiamo attraverso quello che tu
tendono a trovare come te mentre lo fai
il tipo di astrazione è ciò che trovi
che ora hai anche questo segnaposto
per le infrastrutture che hai, non lo sei
stai solo parlando di casi di test
parlando di alcune infrastrutture di test
ci sono alcune idee di design di supporto
e strumenti e strutture che consentono
questo tipo di pensare questo tipo di
astrazione e parleremo di più
su queste cose nel tempo queste
piccoli blob verdi che abbiamo
diversi tipi che aiuteranno
noi raggiungiamo questo livello di astrazione e
mantenerlo così l’idea è quella
abbiamo questa infrastruttura di prova
questo è condiviso tra i casi di test
puoi puoi andare a toccarli
le cose che puoi risolvere risolvono i problemi in uno
posto
Vogliamo vogliamo vogliamo vogliamo pensare
su queste cose in termini di sai
il comportamento del sistema quindi eccoti tu
sai, ecco una lista di cose e solo per
ti confondo che alcune di queste cose sono
sbagliato non penso che ogni test dovrebbe
controlla le condizioni di partenza a
ottimo punto di partenza per i test unitari
ed è un cattivo punto di partenza per questo
tipo di test funzionale perché
di solito si avvia il sistema
caro ci piacerebbe essere in grado di forse
ripartire all’avvio del sistema e
forse sicuramente se è un multiutente
sistema vorremmo essere in grado di avere un sacco
di differenza non ci piace avere un
avviare il sistema in una sola volta e poi avere un sacco
di diversi test eseguiti contro lo stesso
sistema che ne avrà alcuni
implicazioni a sé stante ma ci piacerebbe
essere in grado di separare queste due decisioni
a volte vogliamo voler iniziare
il sistema per un test case ma
a volte non è così che vorremmo essere
in grado di avere la scelta che vogliamo il test
essere una prova generale per la versione di produzione
vorremmo per il momento una versione
il candidato arriva al punto di
dispiegamento in produzione
questo è un non-evento perché questa versione
candidato è già stato schierato
utilizzando questa versione della distribuzione
strumenti e questa configurazione del
infrastruttura molte volte durante un
viaggio e convalida attraverso il
pipeline di implementazione se facciamo questo tipo
di cose ciò che questo porta è che dà
noi questa bella opportunità per il futuro
accelerare il ciclo di feedback dei test
parallelizzando le cose e condividendo il
avviare in testa come come ho detto
passiamo alla prossima nel nostro
elenca così vorremmo che i nostri test fossero
isolato da altri test ora un avvertimento
qui ho passato gran parte della mia carriera
lavorando in una sorta di sistemi multiutente di
una forma o l’ altra
se stai scrivendo software per un
persona individuale a cui è dedicato
quelli che probabilmente probabilmente stanno ottenendo
questi giorni sono sempre più insoliti, ma se
stai scrivendo un software come questo
di questi questi consigli non lo fanno
abbastanza in forma, ma per il resto di noi questo
queste idee sono solo un po ‘di lavoro
pensaci, iniziamo a pensare al test
l’isolamento III pensa che qualsiasi forma di
test in qualsiasi dominio sta valutando
qualcosa in circostanze controllate
e quindi la parte di controllo è importante
l’isolamento è importante nel
contesti a più livelli che vogliamo
essere in grado di isolare il sistema sotto test
vogliamo essere in grado di provare solo
la roba che è il confine del nostro
responsabilità che vogliamo essere in grado di
isolare i casi di test l’uno dall’altro come me
detto prima vorremmo essere in grado di correre
molti di questi in parallelo e non hanno
li incontrano l’un l’ altro e ci piacerebbe
essere in grado di isolare i casi di test da
loro stessi in modo che possiamo eseguire lo stesso test
caso più e più volte penso che lo sia
utile pensare in questi termini se tu
non fare questo ciò che tende ad accadere è
quando inizi a salire di livello e ad arrivare
cicli di feedback più rapidi si trova tutto
tipi di conflitti di condivisione delle risorse e
test si incontrano l’un l’altro quando si
prova ad occhi paralleli e quello comincia a
rendere più difficile accelerare
questo è un attributo molto comune delle persone
che non hanno pensato all’isolamento
prima del tempo le mie cose hanno smesso di funzionare
quindi iniziamo a pensare
isolando l’ isolamento e eccone uno
esempio di quello di cui sto parlando
questo è ciò che tende ad essere molto comune in
grandi imprese immaginiamo che noi
stanno lavorando sul sistema B e sul sistema B
uno di questi sistemi che ce n’è dell’altro
sistema a monte e un altro sistema
a valle è nel mezzo e cosa
cosa è spesso raccomandato in questi tipi
di esempi è necessario testare il
tutto in due parti devi
valutare tutte queste cose insieme
ora c’è un problema con quello se io
voglio essere in grado di specificare con precisione il
dichiari che il mio sistema è attivo per
essere in grado di testarlo e sto solo facendo
che tramite un altro sistema non posso non posso
sii preciso abbastanza ci sono un’intera zattera
di diversi tipi di scenari che io
non può simulare passando attraverso un
primo sistema esterno , se voglio essere
in grado di simulare il sistema mandandomi
spazzatura o il canale di comunicazione di
non riesco a far cadere i sistemi C
simulare quelli in cui non riesco a testare il mio sistema
quelli in quei tipi di scenari, se lo sono
testare il tutto per finire così io
non ho davvero avuto un ottimo modo chiaro
di ottenere il sistema sotto test in
lo stato che voglio che sia in peggio
di quello se sto lavorando al sistema B che sono
non
essere un esperto di sistema a e sistema C
e così il grado in cui posso esercitare
controllo anche se ci sono cose che io
potrei fare da lì che stai andando
essere limitato in base alla mia comprensione
dobbiamo dividere in compartimenti i nostri
capire in modo che le cose possano andare bene
nelle nostre teste quindi questo è un problema
significa che il sistema sul test non lo è
nelle città non controllabili
dichiari quando noi quando facciamo questo tipo di
test, quindi penso che questo sia un
anti-modello
questo non può essere la base per un solido
base per test di accettazione efficaci
quello che ci piacerebbe davvero è invece
qualcosa di più come questo ci piacerebbe essere
in grado di avere i nostri casi di test il più vicino possibile
il sistema in prova come possiamo e poi
catturare l’ output alcuni verificare che siamo
ottenere quello che ci aspettiamo vorremmo essere
in grado di simulare tutti questi diversi
tipi di scenari che vorremmo essere in grado
per iniettare schifo dati e e e e
simulare queste comunicazioni conosciute
fallimenti qualunque cosa ci interessi
circa ci piacerebbe essere in grado di prendere
controllo ci piacerebbe essere in grado di voi
pensare a tipo di sonde putting
attorno al sistema sotto quello sotto test
il che significa che dobbiamo essere molto chiari
su dove i confini per il nostro
il sistema ora è il problema è è quello
quando le organizzazioni dicono che cosa faremmo
come se tu fossi questo è quello che sono
sono preoccupati di queste bollette
preoccuparsi di quelle interfacce che cambiano
e questa è una vera preoccupazione è un it’s a
vero problema una di queste strategie per
questo di cui Mary ha parlato nel
il keynote talk qui è assicurato
quelle interfacce sono sciolte sulla base di
protocolli accoppiati liberi in modo da poter usare a
sistema di messaggistica e che ti dà un
un po ‘ dimenarsi
ma è comunque un problema vero
cosa facciamo per verificare quelle interfacce
Penso che quello che ci piacerebbe davvero è
che vorremmo una serie di test ciascuno
focalizzato sui singoli sistemi come noi
appena descritto se lo facciamo se siamo ancora
facendo questo dal punto di vista di
sistema B anche se quello che vorremmo sapere
del sistema esterno a è soddisfa
le nostre aspettative sul suo protocollo di
comunicazione con noi e quando prendiamo
concentrare il numero di test che noi
bisogno di correre è in realtà abbastanza
più così possiamo definire alcuni test che
diciamo che l’interfaccia è sempre la stessa e
forse anche noi possiamo arrivare al punto di dare
quei test per team a e possono correre
i loro test come parte del loro continuo
infrastruttura di integrazione e se loro
fare un cambiamento che invalida il nostro
assunzione della loro interfaccia che conoscono
che ora abbiamo un’integrazione
problema questo ci dà la possibilità
fare tutto il nostro accurato approfondimento
test dettagliati per ottenere il sistema
sotto test a precisamente lo stato
che vorremmo che tu sia in, ma anche
qualche difesa delle interfacce tra
noi ho usato questa strategia molte volte in
girare incluso con terzo esterno
feste e questo è stato abbastanza per me così
lontano non ho trovato non ho trovato un
problema dove questo è quello che è
questo è causato da una difficoltà
questa è la strategia così come ho detto prima
nel complesso sto lavorando da
l’assunzione di sistemi multi-utente noi
voglio essere in grado di isolare i casi di test che noi
vogliamo che vogliamo essere in grado di correre
molti di questi test e cosa avremmo davvero
come ti piace essere in grado di avviare il
sistema in una sola volta ed eseguono quindi eseguire
un sacco di questi test, al fine di farlo
dobbiamo isolare il test da uno
un altro non possiamo permettercelo di condividere
risorse che non vogliamo che siano
scrivendo per conoscere gli stessi file o
gli stessi set di dati o gli stessi record
nei database o qualunque cosa possa essere
e questo è un po ‘complicato quando pensiamo
su un intero sistema che siamo
valutando una delle buone strategie per
fare se stiamo parlando di un multi-utente
il sistema è qualcosa che chiamo
aliasing funzionale in modo da utilizzare naturale
confini nel sistema per isolare
prova l’ uno dall’altro questo è un altro
uno di quei tipi di tipo 8020
progetto in realtà probabilmente più simile a
95 5 ma per la stragrande maggioranza dei test
casi è possibile utilizzare questo tipo di
isolamento funzionale e ottieni no
problemi e di cosa sto parlando
Immaginiamo che stavamo testando Amazon così
se stessimo testando Amazon ogni singolo
test creerebbe un nuovo account e a
nuovo libro o prodotto e poi se lo fossimo
testando eBay creiamo un nuovo account e
una nuova asta per ogni test case e se
stavamo testando github ne creiamo uno nuovo
account e un nuovo repository per ogni
caso di test si ottiene una sorta di strano
profilo nel sistema in prova perché
ne hai un sacco
repository o molti libri creati
e molti utenti hanno creato ma è a
modo davvero bello di isolare i sistemi
davvero semplicemente dai test case davvero
semplicemente l’uno dall’altro, se vuoi
fallo allora, lo sai che c’è
un altro passo ci piace avere questi
risultati ripetibili ci piacerebbe essere in grado
eseguire lo stesso test case più e più volte
ancora e così se corro lo stesso lo stesso
test due volte dovrei ottenere lo stesso risultato
Ecco un esempio di formaggio quindi ecco qui
qualcuno sta cercando di provare e scrivere un test
caso per comprare il mio libro, quindi abbiamo un negozio
e stiamo creando un libro nel taglio
portata del caso di test , quindi stiamo andando
per effettuare un ordine per il libro e poi
affermeremo che l’ordine è stato
posto ora il pezzo che mi preoccupa
circa qui è un po ‘ così creare un
prenota se eseguo questo test case e io solo
leggilo letteralmente e finisci da qualche parte
memorizzare alcune informazioni nel sistema
e il test che rappresenta quel libro
così la prossima volta che verrò
eseguire quel caso di test sono ora in una
stato diverso ora quando eseguo quel test
caso il libro esiste già l’ultima volta
appena creato ora esiste già forse
un altro al test ha cambiato il
affermare che quel libro è in forse è
esaurito o qualcosa del genere, perché
di un test che è stato eseguito e lo siamo
andando a prendere una collisione che otterremo
un problema un test fiocchi vibrazione qui così
questa è una strategia molto semplice ora
invece di farlo in questo modo quello che facciamo
è quello nel caso di test nel
esempio di un caso di test nostro
infrastruttura ricorda il nostro test
infrastruttura nostra infrastruttura
Scheduie leggere questo come una richiesta piuttosto
di un’istruzione dice ok, lo faresti
come un libro si chiama continuo
consegna, ma in realtà non importa che
è una consegna continua , ti conosco
non mi interessa davvero , quindi lo farò
un nome diverso e lo mapperò
al nome che vuoi nello scope
di questo test eseguito ma all’interno del sistema
sotto test sarà diverso
e non ti interessa così la prossima volta
correrò, otterrò un nome diverso e
ora ho l’ isolamento del test così giusto
usando l’aliasing riempi la sua funzione
facilità per tutti questi funzionali
le entità ci consente di eseguire questi test
casi in parallelo e separati da uno
un altro è banalmente semplice
ma è davvero molto efficace quindi a
buon punto di partenza utilizzare funzionale
le entità di isolamento li alias sempre
mantieni sempre il nome in qualche modo
così che i nomi meridionali saranno
unico per ogni esecuzione di testo quindi tu
può eseguire lo stesso test più e più volte
ancora e non ne avrai nessuna
problemi quindi vorremmo che il nostro test fosse
ripetibile vogliamo essere in grado di utilizzare
test come meccanismo di falsificazione
ci piacerebbe essere in grado di non appena a
il test fallisce , stiamo per scartare il
rilasciare il candidato, quindi vogliamo essere in grado
per fidarmi delle prove, direi che il
test di eventuali test automatizzati di qualsiasi forma
sono in realtà solo preziosi quando sono
in caso contrario è possibile avere un numero di test pari a
ti piace e se ti passano tutti
non so che il test potrebbe essere spazzatura
potrebbe perdere la chiave cosa sono
solo veramente trasmettendo informazioni come
hai una probabilità che forse lo sei
va bene
se hai un sacco di casi di test
stanno passando ma tu conosci veramente solo il
stato del tuo sistema quando un test fallisce
e ti dice che i tuoi sistemi non vanno bene
abbastanza, quindi abbiamo bisogno che il nostro test sia
affidabile non possiamo permetterci i test a fiocchi
non possiamo non poterci permettere i test?
a volte lavoro e altre volte no
ciò significa che dobbiamo controllare
di nuovo essere molto preciso e molto specifico
riguardo al controllo del nostro sistema, facciamolo
immagina di avere un sistema come
questo abbiamo ottenuto un sistema sotto
test e abbiamo qualche sistema esterno
di cui stiamo parlando, stavamo parlando
prima di dove tipo di questi end-to-end
prove che non ci piace molto e
immaginiamo che abbiamo imparato a scrivere
software non da Visual Basic per
manichini ma per qualcos’altro e e
non abbiamo stretto un paio di quelli
due cose abbiamo un’interfaccia locale
tra qui che un’astrazione B di
la comunicazione tra questo sistema
e questo sistema in qualche modo ulteriormente
oltre a ciò abbiamo la comunicazione
canale tra questi due sistemi si
sapere che il resto API o il
prese e qualunque cosa sia il
meccanismo per la comunicazione tra
questi due sistemi quello che vorremmo essere
in grado di fare nell’ambito di un test come
abbiamo detto è che vorremmo scaricare il
sistema esterno non vogliamo davvero
per essere lì è solo confusione e questo
non ci dà un controllo sufficiente
non ci dà il non in realtà
dacci la ripetibilità che non ci dà
la capacità di ottenere veramente il sistema
sotto test allo stato che eravamo
nel fare e tu che vogliamo che sia
dentro e valutarlo in controllo
circostanze quindi cosa possiamo fare allora
attraverso la configurazione possiamo usare il
stessa tecnologia di comunicazione del mondo reale
ma possiamo possiamo fingere di poter mozzare
fuori quei pezzi di comunicazione esterna
sono scritti di nuovo ricordano questi
queste sonde che stiamo mettendo in giro
il nostro sistema ogni punto di esterno
comunicazione vogliamo fingere che vogliamo
di collegare aa stub aaaa falsa versione
del sistema esterno in modo che possiamo
input falsi e raccogliere uscite e fare
asserzioni su ciò che tende ad accadere
è che stiamo facendo quindi ecco che
Ritrova di nuovo lui è il pubblico
interfaccia al nostro sistema e lui è il
ambito del nostro sistema sotto test che abbiamo
la nostra infrastruttura di test alcuni casi di test
ciò che è veramente bello per questi stub è
che vogliamo inserirli nel nostro test
infrastrutture sono distribuite
parte della nostra infrastruttura di test avremmo
piace essere in grado di esprimere idee nel nostro
casi di test che dicono che mi aspetto questo
risultato vorrei il sistema esterno
per fornire questo ingresso e vorremmo
fai tutto questo da attraverso di esso da a
prova in modo astratto e nascondi
quella complessità attraverso qualche canale di pipistrelli
di comunicazione tra il test
infrastruttura e sono gli stub di test
Ti ho guidato nella direzione
di questo già penso davvero che sia così
cruciale utilizzando il linguaggio del
problema del dominio, quindi aiutaci a risolvere molto
di questi problemi in particolare
ci dà il giusto livello di astrazione
essere in grado di esprimere queste idee in a
soluzione senza soluzione di continuità che ci permette di definire
queste specifiche eseguibili senza
descrivendo come funziona il sistema in questo modo
ci aiuta anche a creare questi casi di test
molto rapidamente ci permette di leggere e
capisco lo scopo del nostro test che ho
un cliente lavoro come consulente di consulenza
gente su come fare alcune di queste cose
e consegna continua cose in
generale
Ho un cliente nei Paesi Bassi che
hanno un tipo di funzionalità automatizzata
test abbastanza seriamente per diversi
anni hanno un corpo molto grande di
test funzionali automatizzati e loro
parole che sono orribili che sono
complicato complicato che ci vuole
la persona che ha scritto il test mezzo an
ora 60 minuti per capire cosa
il test sta facendo in modo che abbiano tutto
questi test non sanno cosa sia
la copertura è che non sanno cosa sono
affermando di non sapere se lo è
buono o cattivo anche così la capacità di
capire cosa sta asserendo molto un test
chiaramente essere molto precisi è importante
pensando a queste cose come
specifiche con il comportamento del
sistema ci fornisce con questo livello giusto
dell’astrazione dell’ascrizione e possiamo
inizia a progettare le lingue che ci consentono
per esprimere quelle idee ecco un esempio
Spero che tu possa leggere questo, quindi questo è un
esempio reale dal sistema che ero
parlare di questo è nel
sfera sfera del trading finanziario e
in questo caso stiamo selezionando un accordo
biglietto che è un marchio e il
strumento rappresenta un mercato in cui
puoi scambiare un ordine
un tipo particolare che stiamo verificando per vedere
quale sia il feedback da quell’ordine e
stiamo piazzando un altro ordine e lo siamo
cercando il feedback qui ecco
un altro caso di test questo sta andando
attraverso l’API fix che ho menzionato
prima e stiamo sostituendo un maestro
per entrare nel mercato
in uno stato noto che una istruzione
sta creando il mercato a partire da
o Avani che definisce alcuni utenti per commerciare
in quel mercato e mettendo un mucchio
dei prezzi sul mercato che il
i test successivi possono essere scambiati in tal modo
ricorda quello che ho detto sulla facilità con
scrivendo questi test e ottenendo il
sistema sotto test nello stato che
vorremmo che tu sia molto veloce e
quindi facciamo altre interazioni come
Ho detto prima di ogni caso di test
ha iniziato a mettere in atto il sistema
in una condizione che si desidera
essere in modo che stiamo creando uno strumento
e alcuni utenti che saranno in grado di farlo
commercio e quel genere di cose da ottenere
il sistema per testare questo è il prossimo
livello in basso in modo che questi è questo questo
è questo il test in
per una struttura che i casi di test
condividere e sono e stanno parlando di questo è
un esempio di ordine di posto e puoi vedere
una delle proprietà di questo
è che stiamo usando un sacco di optional
parametri quindi se non mi interessa cosa
ordina che io sia il dettaglio dell’ordine
che sto piazzando posso fornire un posto
ordine con credo che nessun parametro che posso
solo dire di ordine del posto e si farà
uno per me che funzionerà se non lo faccio
cura il dettaglio dell’ordine se voglio
per essere precisi sull’ordine che posso
specificare ogni attributo dell’ordine
ecco un’altra versione di questo che è
per il dispetto no, non ho il
altra versione quindi per altre API
può essere più complicato in realtà cosa
Ho appena mostrate si era un po ‘un
iterazione di dove siamo e noi
realizzato nel tempo che anche a quello
livello non eravamo abbastanza divorziati
da come funzionava il sistema che abbiamo
ho trovato cose qui troppo specifiche
quindi stavamo parlando del trading
interfaccia utente e la fix API e noi
capito che non c’era bisogno di fare
che potremmo astrarre ulteriormente, abbiamo finito
con casi di test come questo questo singolo
il caso di test esprime un desiderio reale
comportamento del sistema che vorremmo essere
in grado di effettuare un ordine in un particolare
mercato di un tipo particolare e lo faremmo
piacerebbe vedere un rapporto di esecuzione a
risposta per il comportamento di quell’ordine
questo caso di test funziona sull’API di correzione
il sito web pubblico e l’API pubblica
che le persone potrebbero usare ma potrebbero usare
scrivi il loro, ma bene questo è uno
il caso di test esprime questo requisito e
può essere soddisfatta in tre diversi
colloca lo stesso cliente di cui stavo parlando
circa prima nei Paesi Bassi sta usando
questa tecnica lì stanno riscrivendo a
sistema legacy e quindi migrazione verso
un approccio microservizi che sono
riscrivendo i loro test di accettazione in questo
tipo di forma e ne hanno due
versioni differenti la versione precedente di
il sistema e la nuova versione di
sistema possono eseguire lo stesso
specifiche e affermano che ottengono
lo stesso comportamento su entrambi i sistemi
è piuttosto potente e dimostra
accoppiamento veramente libero tra il test
caso e il sistema sotto test è possibile
ora immagina che il sistema sotto test sia
in grado di cambiare
abbastanza drammaticamente senza impatto
la natura di questo test non lo fa
molta importanza la natura dell’ordine esso
non importa se stai piazzando
ordine significa compilare alcuni dettagli in a
forma o cliccando su un grafico no
importa questo ha ancora senso
vorremmo essere in grado di testare qualsiasi cambiamento
come parte del nostro processo di sviluppo noi
non voglio solo testare le cose facili
o semplicemente testare i percorsi felici che vogliamo
testare tutti i comportamenti del nostro sistema
quindi sto solo tirando fuori alcuni
diversi casi Lmax
dove ho lavorato abbiamo testato ogni attributo
del sistema abbiamo testato le prestazioni
caratteristiche che vorremmo fare
uccidere selettivamente i bit del sistema e
controlla che quel sistema non ne abbia perso
dati tutti questi tipi di cose ma
Mi concentrerò solo su un paio di
cose così ovvie che tende a
inciampare è tempo è uno di quelli
dipendenze che tendono a entrare nel nostro
molto e credo che ci siano
due strategie per affrontare il tempo
nei test automatici il primo è se
al tuo sistema non interessa molto
tempo ignorarlo
escludere qualsiasi confronto di campi temporali
e basta ignorare quei confronti che
funziona se il tuo sistema non ha importanza
circa il tempo molto l’altro approccio
è prendere il controllo del tempo, quindi cosa faccio
significa per quello
quindi ecco il primo approccio che ignora
tempo il bello vantaggio che questo
l’approccio è che è davvero semplice
solo quando confronti i dati
tra due diverse implicazioni di
il sistema vi si ignorare tutti
il tempo di campi il guaio è che esso
può mancare errori e impedisce il tuo
testare alcuni interessanti e complessi
scenari se il sistema si preoccupa
tempo ed è qui che entra così
test prendendo il controllo del tempo è
molto flessibile è estremamente potente
ti consente di eseguire scenari di lunga durata
puoi farlo in brevi periodi di tempo
simula tutti i tipi di diverso
interazioni con il tempo e vedere le cose dentro
diverso il lato negativo è leggermente
più complesso in termini di
infrastruttura e il setup quindi facciamolo
basta approfondire questo argomento in un altro po ‘
dettaglio ancora mi scuso per il
esempio un po ‘ approssimativo, diciamo
che qualcuno vuole prendere in prestito il mio libro
dalla biblioteca e stanno andando a
asserire che il libro è in ritardo non lo è
in ritardo e poi stanno andando a
il viaggio nel tempo qui è il bit che siamo
interessato a provare e
viaggiare avanti una settimana e poi
affermeranno che il libro
non sono ancora in ritardo, ottengono un tempo
viaggio avanti di quattro settimane
e ora stanno andando ad affermare che il
il libro è ormai scaduto, quindi chiaramente è il
bit di viaggio nel tempo che sono i
bit interessanti in questo scenario così
ecco il nostro sistema sul test e qui
la nostra infrastruttura di test che lo circonda
e in genere in questo tipo di scenario
se abbiamo qualche nozione di tempo in
il nostro sistema da qualche parte ci sarà
qualcosa che assomiglia vagamente a questo
nel codice del sistema che stiamo per fare
avere un quarto di tempo per ottenere il tempo
equivalente in qualunque lingua o
infrastruttura che stai usando di nuovo noi
risolvere questo tipo di problema con
introducendo un livello di indirezione così
invece di chiamare direttamente nel
sistema abbiamo messo il nostro orologio nel modo
così invece di chiedere al sistema per il
tempismo e chiedere un orologio per il tempo e
ogni volta che il sistema chiede il tempo
chiede un orologio ora possiamo iniziare a fare scherzi
con esso
quindi potremmo introdurre un orologio come questo
potremmo avere un orologio che per impostazione predefinita
sta parlando con l’impiegato del sistema e lui
va e prende tempo da
sistema ma possiamo anche imbrogliare e noi
potrebbe impostare il tempo dall’esterno e
restituisce sempre quel tempo qualunque esso sia
è possibile collegarlo al nostro test
infrastruttura in modo che potessimo fare il
istruzioni per il viaggio nel tempo e dire ok così
ci piacerebbe fare questo ci piacerebbe tempo
viaggeremo per interpretare cosa
questo significa in termini di tempo e poi
stiamo andando a impostare il tempo nel
sistema e il test come ho detto questo
ci permette di valutare a lungo andare
scenari nel settore finanziario dove
questi esempi erano alcuni degli esempi
presi da noi spesso hanno una specie di tre
ciclo giorno a volte cicli più lunghi e
non vuoi eseguire un test per tre
giorni per scoprire se funziona, tranne uno
delle cose leggermente divertenti a Lmax
abbiamo parlato con quindici o
venti terzi come parte del nostro
tutto il sistema aziendale che conosci
altre organizzazioni commerciali che si stanno liberando
ospita tutti questi tipi di luoghi e
ogni volta c’era una luce del giorno
risparmi per cambiare all’orologio uno o
altri di questi terzi si sarebbero rotti
e non l’abbiamo mai fatto perché abbiamo provato
abbiamo testato che abbiamo testato la luce del giorno
scenario di cambio di risparmio
nel nostro codice con con questo con questo
approccio al viaggio nel tempo quindi se vogliamo fare
questi tipi di questi tipi di diverso
questi diversi tipi di test noi
probabilmente vogliono iniziare probabilmente
avere alcune caratteristiche diverse
ricorda quello che ho detto all’inizio
sala per la maggior parte dei test che vorremmo
essere in grado di avviare il sistema in una sola volta
e poi eseguire un sacco di test
contro di esso per condividere al costo di
avviare il sistema ma non lo è
andando a lavorare per alcuni di questi test se
stai viaggiando nel tempo che non sei tu
non può essere un viaggio nel tempo in una direzione
e un altro tempo di test viaggiando in
un’altra direzione e un’altra prova no
volendo viaggiare nel tempo presso il
stesso tempo che farà casino
quindi in nessun caso probabilmente ne vorrai uno
versione dedicata nel sistema per
quei test di viaggio nel tempo in modo da poter taggare
quello con quello che abbiamo fatto è stato quello che abbiamo taggato
i test quindi abbiamo fatto test di viaggio nel tempo
e sono ora test assegnati che faremmo
guarda quei tag e li assegna in
due diversi host differenti che abbiamo avuto
prove di test distruttivi che erano
distruggendo parti della nostra infrastruttura o
bit del nostro codice per vedere come il nostro sistema
si alzò di nuovo e probabilmente non lo faresti
voglio condividere quegli ambienti
con prove giornaliere o regolari
test di performance o qualcosa di simile
e poi abbiamo fatto dei test da cui dipendeva
pezzi specifici di hardware e quindi noi
potrebbe andare a cercare gli host che avevano
quel po ‘di hardware e allocare il
le prove per loro qui è un bel po ‘
animazione quindi il ragazzo che ha scritto i test
allocatore questa è una versione abbastanza grezza
le versioni moderne sono molto più grandi e
questo libro era più complesso di quando era lui
stava sviluppando il sistema il test
alligatore e ha fatto questa visualizzazione
per capire cosa sta succedendo qui
è il test parallelo questo è quello che abbiamo
una versione del sistema e un intero
molti host test in esecuzione diversa
casi di test contro questi qui abbiamo
ho preso alcuni di quei test distruttivi
lì che ogni test ha la sua versione
del sistema e può tipo di uccidere
in modo diverso al sistema e valutare
cosa sta succedendo e qui abbiamo un
un sacco di viaggi nel tempo li mette di nuovo alla prova
ha una sua versione del sistema e
sta eseguendo quei test contro questo
versione del sistema e prendendo il controllo
di tempo in quel contesto
vorremmo che il nostro test fosse efficiente noi
voglio essere in grado di eseguire decine di migliaia
di questi test stavo parlando con a
mio collega eccetto che abbiamo lavorato
nel luogo in momenti diversi da El
Max ieri e ha detto che quando io
left del max avevano circa 15.000 di
questi test di accettazione stanno dando
risultati in circa 40 minuti quando se ne andò
che è un anno fa penso che loro
aveva trentamila di questi test
dare risultati in circa 30 minuti è stato
avrebbero aumentato l’hardware e
parallelizzato un po ‘di più ho detto così
puoi eseguire decine di migliaia di questi
test e questo è ciò che vogliamo essere in grado
per arrivare a ottenere questi feedback rapidi
cicli ecco un esempio di one one way
di guardare all’efficienza se lo sei
testare se il tuo ambiente di produzione
sembra questo e il tipico
interazione attraverso l’ ambiente
sembra che questo allora volete che il vostro
ambiente per essere come la produzione
non deve essere una produzione clone di esso
deve rappresentare gli attributi chiave di
il sistema quindi forse il tuo test
l’ambiente sembra così forse è un
un po ‘più complicato di così
un feedback più veloce, ma sta andando a
assomiglia a qualcosa di simile a qualcuno dei tuoi
le interazioni hanno un particolare insolito
un po ‘di hardware o qualcosa del genere
e alcune interazioni assomigliano a questo
forse il tuo ambiente di test è simile
questo ciò che si sta cercando di stabilire in
qui vogliamo essere in grado di eseguire il tuo
software in scenari realistici in
produzione come ambienti in modo che tu possa
valutare la distribuzione il
configurazione l’interazione di tutti
i diversi pezzi e solo il
comportamento dei bit del codice sorgente che
abbiamo scritto quando stiamo scrivendo queste questi
questi casi di test astratti di alto livello in
il nostro linguaggio specifico per il dominio non lo facciamo
voglio valere la pena di preoccuparsi del duro
roba informatica che non vogliamo assolutamente
preoccuparsi di come è il sistema
fornire i comportamenti che vogliamo solo
essere in grado di esprimere le idee del
comportamenti ma oltre quello che non facciamo
voglio essere preoccupante ancora peggio di no
davvero preoccupante per davvero complicato
cose come la concorrenza così dal
prospettiva di ogni passo nel nostro
linguaggio specifico del dominio che vogliamo
essere sincrono vogliamo che sia un
singolo passo sono completamente d’accordo con cosa
Maria ha detto nella nota dominante sul
importanza di
progettazione software asincrona, ma questo è
un posto dove vogliamo noi sincronicità
non sarà in grado di fare un passo nel nostro test
caso completo e valido e
ripetibile e quindi fare il prossimo passo
quindi se stai cercando un se lo sei
lavorando in un sistema asincrono e
vuoi falsificare questo all’interno del tuo dominio
lingua specifica di nuovo hai questo
strato infrastrutturale che ti dà un
posto per farlo, ecco un esempio
questo è questo è il livello DSL questo è
lo strato sotto i casi di test, quindi abbiamo
questa è la cosa condivisa per il posizionamento
ordini immaginiamo che stiamo per inviare
un messaggio di ordine di posto asincrono
stiamo per passare i parametri e
allora aspetteremo un
conferma o esito negativo in un timeout quindi noi
può mangiare sembrare sincrono dal
prospettiva dei casi di test ma è
in realtà asincrono sotto il cofano noi
può nascondere abbastanza piuttosto complesso
interazioni e comportamenti in questo modo
all’interno dello strato di astrazione che a
DSL ci presenta e puoi farlo come te
fare questo altri di coloro po ‘di verde
BLOB nell’infrastruttura che
tende ad andare tendenzialmente a costruire il tuo
proprio modello di dominio piccolo ti aiuta
costruisci e cresca alcune di queste idee
condividere il contesto tra i diversi passaggi in
il caso di test quindi penso di più
i miei sistemi anche-anche molto asincroni
sistemi è vero dire che c’è
quasi sempre un evento naturale conclusivo
a qualsiasi interazione se non c’è forse
dovrebbero essere forse vale la pena guardare
al design del messaggio nel tuo
sistema però se davvero davvero
davvero non riesco a trovare un evento conclusivo
quindi un approccio molto peggiore, ma ancora
un po ‘accettabile è che puoi fare a
meccanismo di polling e time-out per andare e
sembra così facile come è arrivato nel
database come ora andrò e tornare
non guardare mai in pochi secondi nel modo giusto
nel database si passa spostati su quello
tipo di cosa non dovresti mai fare
è questo che vedo questo per tutto il tempo che vado
nei clienti e parlare di aiuto con
la loro strategia di test e il loro codice è
disseminato di dichiarazioni di peso nel
nei loro casi di test questo è simile
crack crack cocaina piede per
testare questo è un anti pan completo è
andando a rendere il tuo software i tuoi test
più lento il migliore
caso è che i test stanno per essere
lento perché ogni volta che sei
andando ad aspettare forse tornato in a
microsecondo non hai dovuto aspettarti
avrei potuto risparmiare quel tempo di attesa peggio
di quello che per lo più accade però lo è
che finisci per introdurre un intero
diverse condizioni di gara che hai
hai appena spostato il gioco e inizi
giocare a tutti i giochi stupidi dalla melodia
i diversi pesi in modo da ottenere
tu eviti le condizioni di gara che sei
mai andando a farlo arrivare al reale
problema che eliminerai ti libererai di
questo e inizia a fare questo genere di cose
invece se fai tutte quelle cose
il prossimo passo nella consegna continua
diventa facile i punti in cui il tuo
il ciclo di feedback inizia a rallentare e tu
bisogno di scalare fino a ottenere un feedback più veloce
di nuovo diventa semplice, ecco la nostra
repository di artefatti abbiamo ottenuto un rilascio
candidato che finisce lì dentro dal nostro
mettere in scena un artefatto dispiegabile
qualunque cosa potrebbe essere la nostra accettazione
l’ambiente di test quando è gratis è
andando a scegliere il più nuovo di quelli
distribuirlo ad un allegato accettazione condivisa
ambiente di test che verrà generato
un sacco di host di test per eseguire tutti
questi diversi casi di test ed è
andando a valutare quel candidato al rilascio
e restituirà i risultati
e tagga il tag in cui si trova il candidato al rilascio
il repository di risorse con lo stato
e questo diventa semplice quando hai finito
queste cose se hai uno stato condiviso
un sacco di bianco condizioni di fusione di
quello che abbiamo avuto tutte queste cose
attenuare la tua capacità di farlo
scala quindi sono un po ‘nel wrap-up
la modalità ora, quindi facciamo abbastanza rapidamente noi
attraverso il riassunto di questo quindi non usare
un sistema di registrazione e riproduzione che sono
veleno non registrare indietro non solo usare
dati di produzione è al massimo è a
esempio del nostro comportamento probabilmente le cose
che fara ‘saltare il tuo software
Sarò nella tua produzione a gestirti
vuoi simulare quelle cose che vuoi
pensare a tutti i casi imbarazzanti che tu
voglio simulare i fallimenti non solo
scaricare i dati di produzione nel test
o è come arrampicarsi
e il montaggio con uno zaino pieno di
rocce
hai appena camminato con questo
questo è un peso
dei dati per tutto il tempo non si assumono
che l’acquisto di prodotti di prova al largo del
scaffale e il consiglio che ti danno
sta per portare a un buon test
strategia la mia esperienza di molti di quelli
le cose sono che non portano a molto
buona strategia di test che devi essere
molto specifico hai bisogno di pensare molto
chiaramente su ciò che vuoi e io
argomenterebbe dal mio punto di vista come a
proponente di consegna continua il
direttiva principale
in questo tipo di approccio all’automazione
test è ciò che vuoi è veloce
feedback che è più importante di
qualsiasi cosa preferirei buttare via un test
ha impiegato troppo tempo per correre poi rallentare il
il ciclo di feedback non ha un separato
test e team di QA penso che i test
a test separati e specialisti QA
sono estremamente preziosi in una squadra ma
dovrebbero lavorare in collaborazione
intimamente con i team di sviluppo
collaborazione a grana fine no
costruire mini cascate dove il
team di sviluppo che lavora fino alla fine
e consegna le cose ai due QA
squadra anche se sono seduti insieme
vuoi fare una valutazione a grana fine
del software fino in fondo
non lasciare che ogni test in esso app in
l’applicazione a meno che la tua applicazione
è accecantemente veloce per iniziare a farlo
ripartire il costo non include i sistemi
al di fuori dell’ambito del tuo sistema essere molto
specifico su quali sono i confini di
il tuo sistema è e prova per quelli
frontiere e non mettere bianco insanguinato
dichiarazioni nei tuoi test sperando che ciò avvenga
risolverà il problema non sarà solo
rendere le tue prove più raffinate e difficili
capire e rallentare quindi non voglio
finire su un downer
quindi scusami, ci stiamo provando
per fare foto e ho finito di correre così
Non ho intenzione di andare avanti con questi
ti assicuri che gli sviluppatori possiedano il
test in modo che completino il feedback
prova il ciclo cosa no come usare la DSL
pensa all’eseguibile dei tester
specifiche che effettuano test di accettazione
parte della definizione di mantenere mantenuto
i test sono isolati l’ uno dall’altro
usando i trucchi di cui ho parlato
qui tieni i tuoi test ripetibili
non sarà in grado di eseguire lo stesso test
e ancora e ottenere gli stessi risultati
ogni volta usa il linguaggio di
il dominio del problema prova davvero il DSL
è più facile di quanto sembri a poco
evolvere queste cose molto rapidamente
fare stub sistemi esterni per definire il
limiti del test del sistema
ambienti di produzione luce provano
configurazione di distribuzione e il
comportamento del tuo sistema
le istruzioni appaiono sincrone al
livello di ciascuna delle dichiarazioni del caso di test
e prova per ogni test di modifica ogni
cambia nel tuo sistema e finalmente fai
preoccupati per le prestazioni del tuo
i test sono preoccupanti per il ciclo di feedback
preoccuparsi se il test richiede ore
è troppo lento se ci vogliono minuti
puoi farcela in pochi secondi
davvero potrebbe prendere prendere prova di prova
le prestazioni sul serio puoi impararlo
la stessa cosa in modo più efficiente se puoi
faccio con che ho fatto grazie per
il tuo tempo ho leggermente finito di correre
[Applausi]
Please follow and like us: