Share
Är du ny på Rails? Ny kodning? Nyfiken om RSpec och hur kan du börja testa? Om så är fallet bör den här artikeln vara en bra utgångspunkt för att du ska kunna komma in i testdriven utveckling. Det kommer att förklara för dig varför och hur, och det kommer att ge dig en överlevnadskit för att gå på din första testning.
Vad är RSpec bra för? RSpec är mycket användbar på enhetstestnivå, testar de finare detaljerna och affärslogiken för din app. Det betyder att testa internals som modeller och controllers av din app. Tester som täcker dina åsikter eller funktionstester som simulerar mer fullständiga användarflöden, som att köpa ett objekt, kommer inte att vara det fokus som RSpec är gjord för. RSpec använder inte en webdrivrutin - som Capybara gör, till exempel - som simulerar en användares interaktioner med en verklig webbplats eller en representation av den.
Testdriven utveckling (TDD), vad är poängen? Tja, det är inte så lätt att svara utan att ge dig några klichéer. Jag hoppas det här låter inte undvikande. Jag kunde ge ett snabbt svar, men jag vill undvika att skicka dig hem hungrig efter att ha bara ett litet mellanmål. Resultatet av denna lilla serie om RSpec och testning ska inte bara ge dig all info för att svara på den här frågan själv utan också ge dig medel och förståelse för att komma igång med testning samtidigt som du känner dig lite säker redan om testningen.
Nybörjare verkar ha svårare att komma in i RSpec och TDD-arbetsflödet än att börja bli farlig med Ruby eller Rails. Varför är det så? Jag kan bara gissa på den här tiden, men å ena sidan verkar litteraturen mest fokuserad på människor som redan har vissa programmeringsförmåga under bältet och å andra sidan att lära sig alla saker som är inblandade för att få en klar förståelse är lite skrämmande. Inlärningskurvan kan vara ganska brant, antar jag. För effektiv testning är det många rörliga delar som berörs. Det är mycket att begära nybörjare som just har börjat förstå ett ramverk som Rails för att se på processen att bygga en app från motsatt perspektiv och lära sig ett helt nytt API för att skriva kod för din kod.
Jag tänkte på hur man kan närma sig detta "dilemma" för nästa generation av kodare som bara letar efter en mjukare start i hela denna sak. Det här är vad jag kom fram till. Jag kommer att bryta den viktigaste syntaxen för dig utan att du antar mycket mer än grundläggande kunskaper om Ruby och lite Rails. I stället för att täcka varje vinkel som möjligt och förvirra dig till döds, kommer vi att gå över din grundläggande överlevnadskit och försöka måla den större bilden. Vi kommer att diskutera "Hur?" Ganska verbosely för att inte förlora nya kodare under vägen. Den andra delen av ekvationen kommer att förklara "varför?"
Om jag har tur, kommer du undan med en bra grund för mer avancerade böcker samtidigt som du känner dig säker på den större bilden. Ok nu, låt oss gå på promenad!
Låt oss komma tillbaka till försöksändamålet. Testar det bra för att skriva bättre kvalitetsprogram? Tja, det här kan diskuteras varmt, men för närvarande skulle jag svara på den här frågan med ett ja-jag är i hipster TDD-läget, antar jag. Låt oss se varför tester ger dina appar ett par fördelar som är svåra att ignorera:
De kontrollerar om ditt arbete fungerar som avsett. Att ständigt bekräfta att du skriver kod som fungerar är väsentlig för din ansökans hälsa och ditt lags sanity.
De testa saker du inte vill testa för hand, tråkiga kontroller som du kan göra för hand-speciellt när du behöver checka det hela tiden. Du vill vara så säker som möjligt att din nya funktion eller din nya klass eller vad som helst inte orsakar några biverkningar i kanske helt oförutsedda områden i din app. Att automatisera den typen av saker sparar inte bara en ton av tid men kommer också att göra testscenarierna konsekventa och reproducerbara. Det som ensam gör dem mycket mer pålitliga än felfritt testning för hand.
Vi vill se till att appen beter sig på ett visst sätt, på ett förväntat sätt. Tester kan i ganska hög grad säkerställa att sättet som användare interagerar med din app fungerar och undviker buggscenarier som du kunde förutse. Tester kontrollerar att din ansökan fungerar som du utformade den - och att den fortsätter att fungera efter att du har infört ändringar. Detta är särskilt viktigt när din testpaket informerar dig om felaktiga scenarier om implementeringar av din app som kan vara gamla och därför inte precis bakom din hjärna längre och inte beaktas när du introducerade ny funktionalitet. Kort sagt, det bidrar till att hålla din app frisk och undviker att introducera massor av buggar.
Automatiserande test gör att du faktiskt testar oftare. Tänk om du måste testa något för 40: e gången av någon anledning. Om det bara är lite tidskrävande, hur lätt blir det att bli uttråkad och hoppa över processen helt och hållet? Sådana saker är det första steget på en sluttning där du kan kyssa en anständig andel av koddäckning hejdå.
Tester fungerar som dokumentation. Va? De specifikationer du skriver ger andra personer på dina lag en snabb startpunkt för att lära sig en ny kodbas och förstå vad den ska göra. Att skriva din kod i RSpec är till exempel mycket uttrycksfull och bildar läsbara blockblock som berättar om en historia om det görs rätt. Eftersom det kan skrivas mycket beskrivande samtidigt som det är ett mycket kortfattat domänspecifikt språk (DSL), träffar RSpec två fåglar med en sten: inte förblir i sitt API och ger dig alla möjligheter att skriva mycket förståeligt testscenarier. Det var det jag alltid gillade om det och varför jag aldrig blev riktigt varm med gurka, som löste samma sak på ett alltför klientvänligt sätt, tror jag.
De kan minimera mängden kod du skriver. I stället för att spika ut som galen, prova saker mer freestyle, kan övningen med att provköra din kod låta dig skriva endast den kod som är nödvändig för att klara dina test. Ingen överskjutningskod. En sak du ofta hör i din framtida karriär är att den bästa koden är kod du inte behöver skriva eller något. Varför? Jo, oftast innebär mer eleganta lösningar mindre mängder kod och kod som du inte skriver - vilket kan vara onödigt - kommer inte att orsaka framtida buggar och behöver inte bibehållas. Så skriver du först testerna innan du skriver implementeringen, ger dig ett tydligt fokus på vilket problem du behöver lösa nästa. Att skriva enbart kod som är nödvändig, och inte av misstag mer, är kanske en underskattad bieffekt som TDD kan förse dig med.
De har en positiv effekt på din design. För mig förstod denna del en glödlampa och fick mig verkligen uppskatta hela testningen. När du skriver dina implementeringar kring mycket fokuserade testscenarier, kommer din kod sannolikt att bli mycket mer avdelad och modulär. Eftersom vi alla är DRY-vänner - "Upprepa inte dig själv!" - och så lite koppling mellan komponenter i din app som möjligt är det en enkel men effektiv disciplin att uppnå system som är väl utformade från grunden. Denna aspekt är den viktigaste fördelen, tror jag. Ja, de andra är också ganska bra, men när tester också resulterar i appar vars kvalitet är bättre på grund av en raffinerad design, säger jag Jackpot!
Det koka ner till pengar också. När du har en stabil app som är lätt att underhålla och lätt att byta, sparar du en hel del pengar på lång sikt. Onödig komplexitet kan enkelt stöta på projekt, och motivationen kommer inte att vara helt hög när ditt lag måste bekämpa din kod eftersom den är skört och dåligt utformad. Bra applikationsdesign kan absolut stödja dina affärsmål och vice versa. Vill du presentera några nya funktioner som är kritiska för ditt företag, men ständigt kämpar du med din arkitektur eftersom den byggdes på sand? Självklart inte, och vi har alla sett många exempel på företag som snabbt försvann för den exakta orsaken. Goda testvanor kan vara en effektiv försvarslinje för sådana situationer.
Ett annat mål som är viktigt är med avseende på kvaliteten på din kod själv. Programvaran du skriver ska vara lätt att förstå för andra utvecklare - så mycket som möjligt, åtminstone. Dina test kan verkligen hjälpa till att förmedla funktionaliteten och avsiktet på din ansökan - och inte bara till andra medlemmar i ett lag utan även i ditt framtida själv. Om du inte berör ett visst avsnitt i koden för ett tag, kommer det att vara praktiskt att uppdatera ditt minne om hur och varför du skrev ett program med dokumentationen som ett verktyg som RSpec ger och RSpec gör det här verkligen bra, exakt faktiskt.
Eftersom din kod alltid kommer att förändras, kommer refactoring din kod alltid att vara en del av att utveckla din programvara. Och eftersom förändring är så bakad i denna process, måste du se till att dessa förändringar inte genererar oväntade biverkningar på överraskande ställen. Testpaketet ger dig ett ganska stramt säkerhetsnät för att känna dig mer bekväm och fri att refactor med gusto. Denna aspekt, bredvid de designfördelar som TDD kan ge dig, är min favoritförmån som en testpaket kan hjälpa dig med. Ändring och förlängning av din kod är en viktig del av innovationen på din redan släppta "produkt" som du behöver ett verktyg som ger dig så mycket frihet som möjligt med den processen. Jag är inte säker på om personer som är kritiska att skriva en omfattande testpaket är mycket oroade över denna aspekt.
Du får en bra chans att bygga nya saker snabbare i senare skeden, eftersom feedbacken från testpaketet ger dig feedback om dina misslyckanden, buggar och begränsningar, mycket snabbare än en människa kan självklart testa. Plus, det ger dig förtroendet att arbeta med ett säkerhetsnät som blir ännu mer värdefull ju längre du går.
I dina appar, särskilt om de har ökat betydligt, vill du kunna lita på din programvara. 100% koddekning låter mycket sötare när du har en webbplats som är ett par år gammal och berört av hundratals utvecklare. Att kunna lita på den nya koden som du introducerar och bygger utöver det är en av de glädje av mjukvaruutveckling som pengar inte kan köpa senare.
skenar ny your_app -T
-T kan du hoppa över testenhet, testramen som följer med Rails.
grupp: utveckling,: test gör gem 'rspec-rails' slutet
bunt
Därefter måste vi köra en generator som levereras med RSpec:
skenor generera rspec: installera
skapa .rspec skapa spec skapa spec / spec_helper.rb skapa spec / rails_helper.rb
Vad det här gör är att ställa in grundstrukturen för dina RSpec-tester inom Rails. Som du kan se från utgången ovan, startade den här generatorn a spec katalog med några filer som du behöver senare. De .rspec filen är en konfigurationsfil som vi inte behöver manipulera för nu. Jag ville bara låta dig veta vad du har framför dig. De andra filerna är självförklarande, men jag ville nämna deras skillnader.
Accentsconagua
spec_helper.rb är för specifikationer som inte är beroende av Rails.rails_helper.rb, Å andra sidan är det för specifikationer som beror på det.Det som inte är uppenbart är att en av dessa filer måste behövas ovanpå dina specfiler (testfiler) för att kunna köra dina tester. Låt oss ta en snabb titt! När du genererar en modell via:
rails generera modell dummy_model namn: sträng
åberopa active_record skapa db / migrera / 20160521004127_create_dummy_models.rb skapa app / models / dummy_model.rb åberopa rspec skapa spec / models / dummy_model_spec.rb
Rails kommer inte bara att skapa de associerade _spec.rb filer för dig, dina specifikationer kommer också automatiskt att ha kräver "rails_helper" som standard ovanpå dina specfiler. Det betyder att du är redo att gå, genast.
kräver "rails_helper" ...
Så med denna inställning kan du testa din Rails app, dina modeller till exempel, och RSpec kommer inte att bli förvirrad om modellklasser som används i Rails. Detta är nödvändigt för att kräva när du behöver saker som Active, ApplicationController och så vidare. Så detta är ditt normala scenario och bör därför vara ditt första logiska val som nybörjare.
kräver spec_helper.rb, Å andra sidan kommer att kasta ett fel om du skriver tester som innehåller affärslogik från din Rails-app. I det scenariot skulle RSpec inte veta vad du pratar om när du vill testa några Rails-modeller, till exempel.
Så lång historia super kort, spec_helper laddar inte Rails-det är det! Naturligtvis kan du gå vild med konfigurationer, men det här är inget jag vill att du ska vara orolig för just nu. Låt oss fokusera på grunderna, hur man kör test och syntaxen. Det bör räcka till förrätter. Låt oss gå vidare!
Du är redo att köra dina tester. RSpec kräver att dina testfiler har ett specifikt suffix som _spec för att förstå vilka filer som ska köras. Om du använder en generator är det här inte ett problem, men om du vill skriva testfiler på egen hand så behöver de sluta. Så du måste lägga till en fil som your_first_test_spec.rb i din spec katalog.
Att använda generatorn för att skapa en dummy-modell gav oss redan spec / modeller / dummy_model_spec.rb. Inte dåligt! En sak kvar att göra innan testerna är klara:
rake db: migrera rake db: test: förbereda
Dessa kommandon kör din migrering för den dummy-modellen vi genererade ovan, och konfigurera testdatabasen med den modellen också. Nu kör vi faktiskt testet:
räfsa
De räfsa Kommando kommer att köra alla dina test, hela testpaketet. Vanligtvis bör du använda det här kommandot när du har slutat någon funktion och vill utöva hela testpaketet.
* Väntar på: (Fel som anges här förväntas och påverkar inte din svits status) 1) DummyModel lägg till några exempel på (eller ta bort) / Användare / vis_kid / projekt / rspec-test-app / rspec-dummy / spec / models / dummy_model_spec .rb # Ännu inte implementerat # ./spec/models/dummy_model_spec.rb:4 Avslutad på 0,00083 sekunder (filer tog 1,94 sekunder att ladda) 1 exempel, 0 fel, 1 pågående
grattis! Du körde precis ditt första RSpec-test. Inte så illa, var det? Självklart var det här ett dummy-test för nu - med dummy testkod genererad av Rails. Den mer fokuserade versionen av att köra dina test - du har faktiskt mycket fler alternativ än bara det - är att driva en enskild fil, till exempel. Så här:
bunt exec rspec spec / models / dummy_model_spec.rb
Detta kommer endast att köras en enda testfil istället för hela testpaketet. Med större applikationer som beror på en stor mängd testfiler blir det en realtidssparare. Men när det gäller att spara tid och testspecifikitet, klarar detta bara ytan, för att vara öppen. Jag tror att vi kommer att täcka mer av hur man rakar bort en betydande tid medan man testar i den tredje artikeln i den här serien. Låt oss se hur långt vi får!
Det andra sättet att utöva hela testpaketet är att helt enkelt springa rspec-med eller utan bunt exec, beroende på din inställning.
bunt exec rspec
En sak som jag bör nämna innan vi går vidare, kan du också köra bara en viss delmängd test. Säg att du bara vill köra alla dina tester för din modellkod:
bunt exec rspec spec / models
Lätt som det!
Jag rekommenderar att vi börjar med de nakna grunderna och titta på några fler alternativ som RSpec tillhandahåller i de följande två artiklarna. Låt oss ta en titt på grundstrukturen i ett test och dyka in i mer avancerade vatten när vi har den här ur vägen.
beskrivaDetta blir ditt bröd och smör eftersom det organiserar dina specs. Du kan referera strängar eller klasser själva:
beskriv Användare gör slut beskriva "En del sträng" slutar
beskriva Sektioner är de grundläggande byggstenarna för att organisera dina test i logiska, sammanhängande grupper för att testa. I princip finns det utrymme för olika delar av din ansökan som du vill testa.
beskriv Användare gör ... sluta beskriva Gäst gör ... sluta beskriva Attacker gör ... slut
Ett bra tips är att strama ditt räckvidd ännu mer. Eftersom vissa klasser kommer att växa ganska väsentligt är det inte en bra idé att ha alla metoder du vill testa för en klass i en enda beskriva blockera. Du kan naturligtvis skapa flera av dessa block och fokusera dem istället på exempel eller klassmetoder. För att göra din avsikt tydligare är allt du behöver för att ge klassnamnet en extra sträng som refererar till metoden du vill testa.
beskriv agent, "#favorite_gadget" do ... sluta beskriva Agent, "#favorite_gun" do ... sluta beskriva Agent, "Gambler" do ... end
På det sättet får du det bästa av båda världarna. Du inkapslar relaterade tester i sina representativa grupper samtidigt som sakerna fokuseras och i en anständig storlek. För användare som är mycket nya till Ruby land, borde jag nämna det # Hänvisar helt enkelt till en förekomstmetod medan punkten . är reserverad för klassmetoder. Eftersom de är inuti strängar, har de inga tekniska konsekvenser här, men de signalerar din avsikt till andra utvecklare och ditt framtida själv. Glöm inte kommatecken efter klassnamnet - det kommer inte fungera utan det! Om en minut när vi kommer till förvänta, Jag ska visa dig varför detta tillvägagångssätt är super bekvämt.
DetInom ramen för beskriva grupper, vi använder en annan omfattning av Det block. Dessa är gjorda för de aktuella exemplen som testas. Om du vill testa förekomstmetoden #favorite_gadget på Ombud klass skulle det se ut så här:
beskriv agent, "#favorite_gadget" gör det "returnerar ett objekt, agentens favoritgränssnitt" gör ... änden
Strängen som du ger till Det block fungerar som huvuddokumentation för ditt test. Inom den anger du exakt vilken typ av beteende du vill eller förväntar dig av den aktuella metoden. Min rekommendation är att inte gå överbord och vara för mycket om det, men samtidigt inte vara alltför kryptisk och förvirra andra med alltför smarta beskrivningar.
Tänk på vad det minsta och enklaste genomförandet av denna del av pusset kan och ska göra. Ju bättre du skriver den här delen desto bättre blir den övergripande dokumentationen för din app. Rusa inte denna del eftersom det bara är en sträng som inte kan göra någon skada, åtminstone inte på ytan.
förvänta()Nu får vi mer till hjärtat av saker. Med den här metoden kan du verifiera eller förfalska den del av systemet du vill testa. Låt oss gå tillbaka till vårt tidigare exempel och se det i (begränsad) åtgärd:
beskriv agent, "#favorite_gadget" gör det "returnerar ett objekt, agentens favoritgränssnitt" förväntar sig (agent.favorite_gadget). till eq 'Walther PPK' änden
förvänta() är den "nya" påståendetypen av RSpec. Tidigare använde vi skall istället. Olika historia, men jag ville nämna det om du stöter på det. förvänta() förväntar dig att du ger det ett objekt och utövar vilken metod som testas på den. Slutligen skriver du det påstådda resultatet på höger sida.
Du har möjlighet att gå med den positiva eller negativa vägen med .till ekv eller .not_to eq till exempel (eq vara kort för lika självklart). Du kan alltid vända logiken runt-det som passar bäst dina behov. Låt oss köra detta oanständiga test och fokusera på den produktion vi fick som ett resultat av vår testinställning:
rspec spec / models / agent_spec.rb
Fel: 1) Agent # favorite_gadget returnerar ett objekt, den favoritgränsen för agenten Fel / Fel: Förvänta (agent.favorite_gadget). Till eq 'Walther PPK'
Läser ganska bra, gör det inte? ** "Agent # favorite_gadget returnerar ett objekt, och den favoritgränssnittet till ombud"** berättar allt du behöver veta:
Om vi hade lämnat strängen som beskriver metoden i beskriva blockera, då skulle produktionen ha varit mycket mindre klar och läsbar:
beskriva Agent gör det "returnerar ett objekt, agenten favoritgodis" förväntar sig (agent.favorite_gadget). till eq 'Walther PPK' änden
Fel: 1) Agent returnerar ett objekt, den favoritgränsen för agenten Fel / Fel: Förvänta (agent.favorite_gadget). Till eq 'Walther PPK'
Visst, det finns andra sätt att kringgå och hantera detta passerar denna information via din Det blockera, till exempel-men den andra metoden är bara enkel och fungerar. Vad som än gör ditt blodflöde, förstås!
Bästa praxis vid testning rekommenderar att vi sammanställer våra tester i fyra olika faser:
Dessa fyra faser är mestadels för läsbarhet och för att ge dina tester en konventionell struktur. Det är ett så kallat testmönster, i grund och botten en övning som samhället allmänt överens om att vara användbart och rekommenderat. Detta hela mönsterämne är ett djupt kaninhål, så vet att jag släpper ut en massa för att inte förvirra nybörjare bland dig till döden.
Under installationen förbereder du det scenario under vilket testet ska köras. I de flesta fall kommer detta att inkludera data som behövs för att vara redo för någon form av motion. Litet tips: överkomplicera inte saker och sätt bara in det lägsta belopp som krävs för att provet ska kunna fungera.
agent = Agent.create (namn: 'James Bond') uppdrag = Mission.create (namn: 'Moonraker', status: 'Briefed')
Den här delen driver faktiskt den sak som du vill testa i denna spec. Kan vara så enkelt som:
status = mission.agent_status
Nu verifierar du om din påstående om testet uppfylls eller inte. Så du testar systemet mot dina egna förväntningar.
förvänta (status) .not_to eq 'MIA')
Ramverket tar hand om problem med minne och databasrengöring - en återställning, i princip. Det finns inget för dig att hantera just nu. Målet är att få tillbaka ett orört tillstånd för att köra nya tester utan några överraskningar från de pågående. Låt oss se vad det här skulle innebära i ett exempel:
beskriva Agent, "#favorite_gadget" gör det "returnerar ett objekt, agentens favoritgränssnitt" gör # Setup agent = Agent.create (namn: 'James Bond') q = Quartermaster.create (namn: 'Q') q .technical_briefing (agent) # Exercise favorite_gadget = agent.favorite_gadget # Verifiera förvänta (favorite_gadget) .to eq 'Walther PPK' # Teardown är för närvarande mestadels hanterat av RSpecs självändning
Som du kan se, i det här exemplet separerade vi övningen och verifierar faser tydligt från varandra, medan i de andra dummyexemplen ovan, Förvänta (agent.favorite_gadget). till eq 'Walther PKK, Vi blandade båda faserna tillsammans. Båda är giltiga scenarier och har sin plats. De nya linjerna bidrar också till att visuellt skilja hur testet är strukturerat.
Nu kommer den svåra delen, vad ska man testa och hur. Enligt min mening är detta den aspekt av testning som är mest förvirrande för nykomlingar - och förståeligt så! Du är ny på språket och ramverket och vet ofta inte ens vad du inte vet. Hur skriver du test för det? Mycket bra fråga.
Jag är väldigt uppriktig, du är inte mest sannolikt - och du kommer inte för ganska länge. Att bli bekväm med dessa saker tar ett tag. När du har en mentor eller närvarar i vissa startläger och så har du möjlighet att direkt lära av erfarna personer. I så fall kommer dina framsteg i denna avdelning naturligtvis att vara annorlunda.
Å andra sidan, om så många andra där ute-du lär dig själv dessa saker, kommer tålamod att vara nyckel. Att läsa alla böcker och artiklar får dig säkert i rätt riktning, men jag tror att testningen behöver mycket mer avancerade pusselbitar på plats för att du ska kunna få full mening och kanske ännu viktigare innan du känner dig bekväm med det.
Den "goda" nyheten är att detta inte är ovanligt och vi har alla varit där. Uthållighet är viktig. Du kan göra det här, det är ingen raketvetenskap, men det kommer ta ett tag tills du kan skriva en ansökan på ett effektivt sätt från annat håll - från tester perspektiv menar jag. För nu, fortsätt trycka, ha det roligt, gör misstag, skriv apps, kopiera handledning och whatnot tills lampan släcks.
När du skriver dina individuella test, vill du göra sina föremål gör det enklaste möjligt att uppnå ditt mål. Mycket fokuserade test är verkligen viktiga. Du vill utforma din ansökan via mycket enkla steg och följ sedan de fel som din testpaket ger dig.
Använd bara vad som är nödvändigt för att få appen grön. Inte mer, inte mindre! Det är den "drivna" delen i testdriven utveckling. Ditt arbete styrs av dina testers behov.
