Kjerneideen for testdrevet utvikling (TDD) er å skrive tester før du skriver noen funksjonskode, og deretter skriver du bare den minste mulige koden som kreves for å gjøre testene bestått. Det kan høres rart å utvikle på denne måten, men det er faktisk ganske nyttig, da testbase dobler som en delvis spesifikasjon av hovedkoden.
Gitt en slik enkel premiss, men det er en utrolig mengde terminologi og teknikker. I denne artikkelen samler jeg de viktigste begrepene og buzzwords som du kanskje hører, og definerer dem.
Test-første programmering tillater funksjonelle tester på høyt nivå.
Det høyeste testnivået bekrefter at programvaren oppfyller kundens krav. Godkjennelsesprøving kjøres ofte i miljøer så nær produksjon som mulig. Se funksjonell testing og systemtesting.
Påstander er uttalelser som utfører en faktisk kontroll på programvarens utgang. Generelt kalles en enkelt funksjon hevde
er nok til å uttrykke noen sjekk. I praksis har testbibliotekene ofte mange assertfunksjoner for å møte spesifikke behov (for eksempel assertFalse
, assertEqual
og mer) for å gi bedre analyse og bedre produksjon.
En testteknikk som inkorporerer testdobles til programvaren, og hevder at den kaller riktige metoder i riktig rekkefølge. Se etter et eksempel. Se også statlig testing.
En delmengde av TDD drevet av behovet for klarere kommunikasjon og riktig dokumentasjon. BDD er kanskje den største nyere utviklingen i TDD.
Kjerneidéen er å erstatte forvirrende og utvikler-sentrisk terminologi (tester, suiter, påstander etc) med allestedsnærværende språk at alle deltakende interessenter (inkludert ikke-teknisk stab, og eventuelt kunder) kan forstå.
Se brukerhistorie.
Et generelt prinsipp for å teste hvor personen som skriver tester ikke kjenner eller unngår internals av programvaren, i stedet velger å teste det offentlige grensesnittet av programvaren strengt ved sitt grensesnitt eller spesifikasjon. Se test av hvite bokser.
En strategi for å skrive tester for å fange opp-og-en og andre lignende typer feil. For å utføre grenseverdietesting, teste inngangene rundt visse mulig problematiske grenser. I tilfelle heltall kan dette være 0
, -1
, MIN_INT
, MAX_INT
og andre lignende verdier.
Påstander er uttalelser som utfører en faktisk kontroll på programvarens utgang.
En dummy er en type testdobbel som aldri brukes av selve programvaren, men brukes kun i testing for å fylle nødvendige parametere.
Fakes er testdobler som implementerer den nødvendige funksjonaliteten på en måte som er nyttig i testing, men som også effektivt diskvalifiserer det fra å bli brukt i produksjonsmiljø. For eksempel kan en nøkkelverdatabase som lagrer alle verdier i minnet og mister dem etter hver utførelse potensielt tillate at tester kjører raskere, men tendensen til å ødelegge data vil ikke tillate at den brukes til produksjon.
Et bestemt miljø som må settes opp før en test kan kjøres. Det består i all hovedsak av å sette opp alle testdoblinger og andre avhengigheter for programvaren som testes: for eksempel å sette inn forhåndsdefinerte data i en falsk database, sette opp bestemte katalogstrukturer i falsk filsystem, sette opp egenskaper på avhengigheten av programvare under test.
En testing på høyt nivå som bekrefter at alle forretningskravene til produktet er oppfylt. Funksjonell testing innebærer vanligvis bruk av brukerhistorier for å fokusere på et høyere krav til å dekke så mange bruksscenarier som mulig. Se godkjenningstesting og systemtesting. For eksempel:
# I dette eksemplet kontrollerer vi at nettsiden på nettsiden virker som forventet. Åpne "example.com" clickOn 'om oss' assertThereIs 'Vi er et lite eksempel selskap'
En colloquialism for en bestått samling av tester, eller noen ganger en bestemt beståttest. Se rødt.
En midtstilt testaktivitet som bekrefter et bestemt sett med moduler fungerer riktig sammen. Integrasjonstester er som enhetstester uten å bruke testdobles for en viss delmengde av avhengigheter, i hovedsak å teste samspillet mellom programvaren sin avhengighet. Eksempel:
# I dette eksemplet kontrollerer vi at den nyregistrerte brukeren, # som ble henvist av en annen bruker, får opprettet et "vennskap" på stedet. # Her kontrollerer vi samspillet mellom skjemakontrolleren, # database og en Bruker aktiv post db = ny Feil Db u1 = db.createUser (navn = 'john') RegistrationForm (db, navn = "kate", referert = "john ") .save () assert (u1.hasFriend ('kate'))
En type testdobbel laget for en bestemt test eller test sak. Den forventer å bli kalt et bestemt antall ganger og gir et forhåndsdefinert svar. På slutten av testen oppstår en feil, hvis den ikke ble ringt så mange ganger som forventet. En mock med strenge forventninger er en del av påstandsrammen. Eksempel:
# I dette eksemplet bruker vi en mock-database for å kontrollere at skjemaet # bruker databasen til å lagre den nye brukeren. # Hvis databasen ikke er blitt kalt på slutten av testen, vil # mocken selv hevde en påståelsesfeil. db = new Mock Db db.expect ('save'). en gang (). med (navn = 'john') RegistrationForm (db, navn = "john").
En måte å utvide og endre oppførselen til eksisterende objekter og klasser i et programmeringsspråk. Monkey-patching kan brukes som et alternativ til avhengighetsinjeksjon og testdobles ved direkte å endre eksisterende funksjoner som kalles av programvaren under test (og endre dem tilbake etter testen).
# I dette eksemplet erstatter vi standardbibliotekfunksjonen # for å hindre at testen bruker et ekte filsystem filsystem.listdir = f (navn) -> ['.', '...', 'foo', 'bar']; assertEqual (MyFileSearch ('foo'). count (), 1)
En colloquialism for en sviktende samling av tester eller noen ganger en bestemt feiltest. Se grønt.
Prosessen med å forbedre implementeringsdetaljer for kode uten å endre funksjonaliteten.
Refactoring uten tester er en veldig sprø prosess, da utvikleren som gjør refactoring, aldri kan være sikker på at hans forbedringer ikke bryter noen deler av funksjonaliteten.
Hvis koden ble skrevet med testdrevet utvikling, kan utvikleren være sikker på at hans refactoring var vellykket så snart alle tester passerer, da all nødvendig funksjonalitet i koden er fortsatt korrekt.
En programvarefeil som vises i en bestemt funksjon etter en hendelse (vanligvis en endring i koden).
Scenarietesting
Se funksjonell testing.
En prosess for å forberede en armatur. Se teardown. Eksempel:
# I dette eksempelet forbereder vi en falsk database med noen falske verdier # som vi trenger over flere tester db = ny Fake Db db.createUser (navn = 'john') db.createUser (name = 'kate') db.createFriendship ( 'john', 'kate')
En form for enhetstesting når testkoden gir test dobler til og hevder at tilstanden til disse dobblingene har blitt modifisert på riktig måte. Se oppførselstesting.
# I dette eksemplet, som i et eksempel på mock objekter, # vi vil kontrollere at skjemaet bruker databasen til å lagre den nye brukeren. # Denne gangen vil vi sjekke tilstand, i stedet for atferd db = ny Fake Db RegistrationForm (db, navn = "john"). Lagre () assertInList ('john', db.listUsers ())
Fakes er testdobler som aldri brukes av selve programvaren.
En type testdobbel som kan svare på programvaren som testes med forhåndsdefinerte svar. I motsetning til mocks, kontrollerer stubber vanligvis ikke om de er blitt kalt ordentlig, men bare sørg for at programvaren kan kalle dens avhengigheter.
En testing av høyt nivå når hele programvaren testes opp til bunn. Dette inkluderer funksjonell testing, samt kontroll av andre egenskaper (som ytelse og stabilitet).
En forkortelse for programvare under test. Brukes til å skille programvaren under test fra avhengighetene.
En prosess med å rydde opp en armatur. I søppel-innsamlede språk håndteres denne funksjonaliteten for det meste automatisk. Se oppsett.
Den minste mulige kontrollen for korrekthet. For eksempel kan en enkelt test for et webskjema være en kontroll på at når du oppgir en ugyldig e-postadresse, advarer skjemaet brukeren og foreslår en løsning. Se test saken.
En samling av tester gruppert av et attributt. For eksempel kan et test tilfelle for et webskjema være en samling av tester som kontrollerer oppførselen til skjemaet for forskjellige gyldige og ugyldige innganger.
funksjon t1: assertNoError (RegistrationForm (navn = 'john', passord = "hestbatteri stift korrekt"). lagre ()) funksjon t2: assertError (manglende passord, registreringsform (navn = 'john'). lagre ()) funksjon t3: assertError (StupidPassword, RegistrationForm (navn = 'john', passord = "passord"). lagre ())
Brukerhistorier defineres vanligvis på menneskelige språk for å fokusere på brukeropplevelse i stedet.
Enhver type metriske som forsøker å estimere sannsynligheten for at SUTs viktige oppførsel fortsatt ikke er dekket av testene. Mest populære teknikker inkluderer forskjellige typer kode dekning: teknikker som sørger for at alle mulige kodesetninger (eller funksjoner eller logiske grener i koden) er blitt utført under testingen.
En prosess med TDD-utvikling. Gitt at TDD-utviklingen starter med å skrive noen få tester, er det klart at testpakken starter rødt. Så snart utvikleren implementerer all ny testet funksjonalitet, blir testene grønne. Nå kan utvikleren sikkert reflektere sin implementering uten risiko for å introdusere nye feil, da han har en testpakke å stole på. Når refactoring er fullført, kan utvikleren starte syklusen igjen ved å skrive flere tester for mer ny funksjonalitet. Dermed er rød-grønn-refaktor test syklus.
Test dobbelt
Testdobler er objekter testkoden oppretter og går til SUT for å erstatte ekte avhengigheter. For eksempel skal enhetstestene være veldig raske og bare teste et bestemt program.
Av disse årsakene blir avhengighetene, som for eksempel en database eller filsysteminteraksjonsbibliotek, vanligvis erstattet av objekter som virker i minnet i stedet for å snakke med en ekte database eller filsystem.
Det er fire hovedkategorier av testdobler: dummies, fakes, stubs og mocks.
En samling av testtilfeller som tester en stor del av programvaren. Alternativt, alle test tilfeller for en bestemt programvare.
Hvitboksforsøk gir en dypere analyse av mulige problemer i koden.
Test-første programmering er et litt bredere uttrykk for testdrevet utvikling. Mens TDD fremmer tett kopling mellom skrive tester (vanligvis enhetstester) og skriving av koden, gjør test-første programmering det mulig for høyt nivå funksjonstester i stedet. Imidlertid er skillet i generell bruk sjelden notert, og to vilkårene er vanligvis brukt om hverandre.
Laveste nivå test teknikk bestående av test tilfeller for de minste mulige enheter av kode. En enkelt enhetstest kontrollerer vanligvis bare en bestemt liten oppførsel, og en testenhet for enheten dekker vanligvis alle funksjoner i en bestemt enkeltfunksjon eller klasse.
En enkelt beskrivelse av en bestemt gruppe mennesker som er villige til å utføre en bestemt oppgave ved hjelp av SUT for å oppnå et bestemt mål. Brukerhistorier defineres vanligvis på menneskelige språk, ved hjelp av enkle, bruker-sentrale vilkår for å unngå å vurdere implementeringsdetaljer og å fokusere på brukeropplevelse i stedet. For eksempel:
Som bruker vil jeg kunne finne vennene mine på denne nettsiden i adresseboken, i stedet for å se etter dem en etter en, fordi det vil spare meg mye tid.
Hvitboksprøving er en testteknikk når en person som utfører testingen vet om, eller kan lese, internettet til SUT. I motsetning til den mer vanlige svartboksen testing, gjør hvitboks testing en dypere analyse av mulige problemer i koden.
For eksempel kan en bestemt grenseverdi ikke se ut som en basert utelukkende på spesifikasjonen av programvaren, men det kan være åpenbart fra gjennomføringen av det.
I tillegg er noen testdekningsteknikker vanligvis per definisjon en del av white-box testing.