Share
Kärnidén för testdriven utveckling (TDD) skriver skrivprov innan du skriver någon funktionskod, och skriver då endast den minsta möjliga mängd kod som krävs för att testen ska passera. Det kanske låter konstigt att utvecklas på detta sätt, men det är faktiskt ganska användbart, eftersom testbasen fördubblas som en delspecifikation av huvudkoden.
Med tanke på en sådan enkel förutsättning finns det dock en fantastisk mängd terminologi och tekniker. I den här artikeln samlar jag de viktigaste termerna och buzzwords som du kanske hör och definierar dem.
Test-första programmeringen möjliggör funktionella test på hög nivå.
Den högsta testnivån bekräftar att programvaran uppfyller kundens krav. Godkännandetestning körs vanligen i miljöer så nära produktionen som möjligt. Se funktionell testning och systemtestning.
Påståenden är uttalanden som utför en faktisk kontroll av programvarans utdata. I allmänhet kallas en enda funktion hävda räcker för att uttrycka någon kontroll. I praktiken har testbibliotek ofta många assertfunktioner för att möta specifika behov (t.ex. assertFalse, assertEqual och mer) för att erbjuda bättre analys och vänligare produktion.
En testteknik som innehåller testdouble till programvaran och hävdar att det kallar korrekta metoder i rätt ordning. Se mock för ett exempel. Se även statstestning.
En delmängd av TDD som drivs av behovet av tydligare kommunikation och korrekt dokumentation. BDD är kanske den största senaste utvecklingen i TDD.
Kärnan är att ersätta förvirrande och utvecklingscentrerad terminologi (tester, sviter, påståenden etc) med allestädes närvarande språk att alla deltagande intressenter (inklusive icke-teknisk personal och eventuellt kunder) kan förstå.
Se användarberättelse.
En allmän princip i testning där den person som skriver tester inte känner till eller undviker programvarans internaler, väljer istället att testa det offentliga gränssnittet för programvaran strängt genom gränssnittet eller specifikationen. Se testning i vitlådan.
En strategi för att skriva tester för att fånga upp-och-en och andra liknande typer av fel. För att utföra gränsvärdetestning, testa ingångarna kring vissa eventuellt problematiska gränser. I händelse av heltal kan detta vara 0, -1, MIN_INT, MAX_INT och andra liknande värden.
Påståenden är uttalanden som utför en faktisk kontroll av programvarans utdata.
En dummy är en typ av testdubbel som aldrig används av den aktuella mjukvaran, men används endast för testning för att fylla på nödvändiga parametrar.
Fakes är testdouble som implementerar den nödvändiga funktionaliteten på ett sätt som är användbart vid testning, men som också effektivt diskvalificerar det från att användas i produktionsmiljö. Till exempel kan en nyckelvärdesdatabas som lagrar alla värden i minnet och förlorar dem efter varje körning möjligen tillåta att test körs snabbare, men dess tendens att förstöra data skulle inte tillåta att den används för produktion.
En viss miljö som måste ställas in före ett test kan köras. Det består i allmänhet av att konfigurera alla testdouble och andra beroenden för den programvara som testas: såsom att införa fördefinierade data i en falsk databas, konfigurera viss katalogstruktur i falskfilsystemet, konfigurera egenskaper på beroendet av programvara som testas.
En testnivå på hög nivå som verifierar att alla företags krav på produkten är uppfyllda. Funktionell testning involverar vanligtvis användarhistorier för att fokusera på en högre nivå av krav för att täcka så många användningsscenarier som möjligt. Se acceptanstest och systemtestning. Till exempel:
# I det här exemplet kontrollerar vi att webbplatsens cirka sida fungerar som förväntat öppet "example.com" clickOn "om oss" hävdar Det finns "Vi är ett litet exempelföretag"
En kollokialism för en passande samling av test, eller ibland ett särskilt provningstest. Se rött.
En mittnivå testningsaktivitet som verifierar en viss uppsättning moduler fungerar korrekt tillsammans. Integrationstester är som enhetsprov utan att använda testdouble för en viss delmängd av beroenden, vilket i huvudsak testar interaktionerna mellan programvarans beroende. Exempel:
Accentsconagua
# I det här exemplet kontrollerar vi att den nyregistrerade användaren, # som hänvisades av en annan användare, skapar en "vänskap" på plats. # Här kontrollerar vi interaktionen mellan formulärkontrollen, # databasen och en användaraktiv post db = ny Fake Db u1 = db.createUser (namn = 'john') RegistrationForm (db, namn = "kate", refer = "john ") .save () assert (u1.hasFriend ('kate')) En typ av test dubbel skapad för ett visst test eller testfall. Det förväntar sig att man ringer ett visst antal gånger och ger ett fördefinierat svar. I slutet av testet uppstår en skott ett fel om det inte kallades så många gånger som förväntat. En mock med strikta förväntningar är en del av påståendet. Exempel:
# I det här exemplet använder vi en mock-databas för att kontrollera att formuläret # använder databasen för att lagra den nya användaren. # Om databasen inte har blivit kallad i slutet av testet, kommer # mocken själv att hävda ett påståendefel. db = new Mock Db db.expect ('save'). en gång (). med (namn = 'john') RegistrationForm (db, namn = "john"). Ett sätt att utvidga och ändra beteendet hos befintliga objekt och klasser på ett programmeringsspråk. Monkey-patching kan användas som ett alternativ till beredskapsinjektion och testdouble genom direkt modifiering av befintliga funktioner som kallas av programvaran som testas (och byter dem tillbaka efter testet).
# I det här exemplet ersätter vi standardbiblioteksfunktionen # för att förhindra att testet använder ett riktigt filsystemfilsystem.listdir = f (namn) -> ['.', '...', 'foo', 'bar']; assertEqual (MyFileSearch ('foo'). count (), 1) En colloquialism för en felaktig samling av test eller ibland ett särskilt fel test. Se grön.
Processen att förbättra implementeringsdetaljer för kod utan att ändra dess funktionalitet.
Refactoring utan test är en väldigt spröd process, eftersom utvecklaren som gör refactoring aldrig kan vara säker på att hans förbättringar inte bryter mot delar av funktionalitet.
Om koden skrevs med testdriven utveckling kan utvecklaren vara säker på att hans refactoring lyckades så snart alla tester passerar, eftersom alla nödvändiga funktioner i koden fortfarande är korrekta.
En programvarufel som uppträder i en viss funktion efter en händelse (vanligtvis en ändring i koden).
Scenariotestning
Se funktionell testning.
En process för att förbereda en fixtur. Se teardown. Exempel:
# I det här exemplet förbereder vi en falsk databas med några falska värden # som vi behöver över flera test db = ny Fake Db db.createUser (namn = 'john') db.createUser (name = 'kate') db.createFriendship ( 'john', 'kate')
En form av enhetstestning när testkoden ger test dubblerar till och hävdar att tillståndet för dessa dubblar har modifierats på ett korrekt sätt. Se beteendeprovning.
# I det här exemplet, som i ett exempel på mocka objekt, # kommer vi att kontrollera att formuläret använder databasen för att lagra den nya användaren. # Den här gången kommer vi att kontrollera tillstånd, istället för beteende db = ny Fake Db RegistrationForm (db, namn = "john"). Spara () assertInList ('john', db.listUsers ()) Fakes är testdouble som aldrig används av själva programvaran.
En typ av testdubbel som kan svara på programvaran som testas med fördefinierade svar. Till skillnad från mocks brukar stubben vanligtvis inte kontrollera om de har kallats ordentligt, men bara se till att programvaran kan ringa dess beroenden.
En testnivå på hög nivå när hela programvaran testas uppifrån och ned. Detta inkluderar funktionell testning, liksom kontroll av andra egenskaper (som prestanda och stabilitet).
En förkortning för programvara som testas. Används för att skilja programvaran under test från dess beroende.
En process för att städa upp en armatur. I soporuppsamlade språk hanteras denna funktion mestadels automatiskt. Se inställningen.
Den minsta möjliga kontrollen för korrekthet. Ett enkelt test för ett webbformulär kan till exempel vara en kontroll som varnar när användaren anger en ogiltig e-postadress och antyder en åtgärd. Se testfallet.
En samling av tester grupperade med ett attribut. Exempelvis kan ett testfall för en webbformulär vara en samling av test som kontrollerar formens beteende för olika giltiga och ogiltiga ingångar.
funktionen t1: assertNoError (RegistrationForm (namn = 'john', lösenord = "hästbatteri stift korrekt"). spara ()) funktion t2: assertError (MissingPassword, RegistrationForm (namn = 'john'). Spara ()) funktion t3: assertError (StupidPassword, RegistrationForm (namn = 'john', lösenord = "lösenord"). spara ())
Användarberättelser definieras vanligtvis på mänskliga språk för att fokusera på användarupplevelse istället.
Vilken typ av mätning som helst som försöker uppskatta sannolikheten för SUT: s viktiga beteende fortfarande inte omfattas av test. Mest populära teknikerna inkluderar olika typer av kod täckning: Tekniker som ser till att alla möjliga kodsatser (eller funktioner eller logiska grenar i koden) har genomförts under testningen.
En process av TDD-utveckling. Med tanke på att TDD-utveckling börjar med att skriva några tester är det klart att testpaketet börjar rött. Så snart utvecklaren genomför alla nyprövade funktionaliteter blir testen grön. Nu kan utvecklaren på ett säkert sätt reflektera sin implementering utan risken att införa nya buggar, eftersom han har en testpaket att förlita sig på. När refactoring är klar kan utvecklaren starta cykeln igen genom att skriva fler test för mer ny funktionalitet. Således testcykel med röd grön refaktor.
Test dubbel
Testdouble är objekt som provkoden skapar och skickar till SUT för att ersätta verkliga beroenden. Enhetsprovningar bör till exempel vara mycket snabba och endast testa ett visst program.
Av dessa skäl är dess beroende, till exempel en databas eller filsystem, interaktionsbibliotek, vanligtvis ersatta av objekt som fungerar i minnet istället för att prata med en riktig databas eller filsystem.
Det finns fyra huvudkategorier av testdouble: dummies, fakes, stubs och mocks.
En samling testfall som testar en stor del av programvaran. Alternativt alla testfall för en viss programvara.
White-box testning möjliggör en djupare analys av eventuella problem i koden.
Test-första programmeringen är en något bredare term för testdriven utveckling. Medan TDD främjar en tät koppling mellan skrivprov (vanligtvis enhetstester) och skrivning av koden tillåter test-första programmering istället höga funktionella test. Skillnaden i allmän användning noteras emellertid sällan, och två termer används vanligtvis utbytbart.
Den lägsta nivån testteknik som består av testfall för de minsta möjliga enheterna av kod. Ett test av enhetsenhet kontrollerar vanligtvis bara ett visst litet beteende, och ett testenhetstest täcker vanligtvis alla funktioner för en viss enskild funktion eller klass.
En enda beskrivning av en viss grupp människor som är villiga att utföra en viss uppgift med hjälp av SUT för att uppnå ett visst mål. Användarberättelser definieras vanligtvis på mänskliga språk, med hjälp av enkla, användarcentrerade villkor för att undvika överväganden om implementering och att fokusera på användarupplevelse istället. Till exempel:
Som användare vill jag kunna hitta mina vänner på den här webbplatsen i min adressbok, istället för att leta efter dem en efter en, för det kommer att spara mig mycket tid.
Testning av vitlådor är en testteknik när en person som utför testningen vet, eller kan läsa, internt i SUT. Till skillnad från den vanligaste svart-box-testet möjliggör white-box-testning en djupare analys av eventuella problem i koden.
Till exempel kan ett visst gränsvärde inte se ut som en baserat uteslutande på programvarans specifikation, men det kan vara uppenbart från genomförandet av det.
Dessutom är alla testdäckstekniker vanligtvis per definition en del av white-box-testning.
