Share
Ben je nieuw bij Rails? Nieuw bij coderen? Benieuwd naar RSpec en hoe u kunt beginnen met testen? Als dit het geval is, zou dit artikel een goed startpunt moeten zijn om in een testgestuurde ontwikkeling te komen. Het zal je het waarom en het hoe uitleggen, en het zal je een overlevingspakket geven om je eerste testvlucht te maken.
Waar is RSpec goed voor? RSpec is erg handig op het niveau Unit Test en test de fijnere details en de bedrijfslogica van uw app. Dat betekent het testen van de internals, zoals modellen en controllers van uw app. Tests die betrekking hebben op uw weergaven of functies testen die meer volledige gebruikersstromen simuleren, zoals het kopen van een artikel, zullen niet de focus zijn waar RSpec voor is gemaakt. RSpec maakt geen gebruik van een webstuurprogramma - zoals Capybara dat bijvoorbeeld doet - dat de interacties van een gebruiker met een daadwerkelijke site of een weergave ervan simuleert.
Testgestuurde ontwikkeling (TDD), wat is het punt? Nou, dat is niet zo gemakkelijk te beantwoorden zonder je clichés te geven. Ik hoop dat dit niet ontwijkend klinkt. Ik zou snel een antwoord kunnen geven, maar ik wil voorkomen dat ik je hongerig naar huis stuur na slechts een kleine snack. Het resultaat van deze kleine serie over RSpec en testen moet je niet alleen alle informatie geven om deze vraag zelf te beantwoorden, maar je ook de middelen en het begrip geven om aan de slag te gaan met testen, terwijl je je al een beetje zeker voelt over het testen van dingen.
Beginners lijken het moeilijker te hebben om in RSpec en de TDD-workflow te komen dan te beginnen gevaarlijk te worden met Ruby of Rails. Waarom is dat? Ik kan alleen maar raden op dit punt, maar aan de ene kant lijkt de literatuur vooral gericht op mensen die al wat programmeervaardigheden onder hun riem hebben, en aan de andere kant, het leren van alle dingen die betrokken zijn om een duidelijk begrip te hebben is een beetje ontmoedigend. De leercurve kan behoorlijk steil zijn, neem ik aan. Voor effectieve testen zijn er veel bewegende delen bij betrokken. Het is veel om te vragen aan nieuwkomers die net een raamwerk zoals Rails zijn gaan begrijpen om te kijken naar het proces om een app vanuit het tegenovergestelde perspectief te bouwen en een volledig nieuwe API te leren om code voor uw code te schrijven.
Ik dacht na over hoe dit "dilemma" te benaderen voor de volgende generatie codeerders die alleen maar op zoek zijn naar een soepeler begin van dit hele ding. Dit is wat ik bedacht. Ik zal de meest essentiële syntaxis voor je onderbreken zonder veel meer te veronderstellen dan basiskennis van Ruby en een klein beetje Rails. In plaats van elke mogelijke hoek te overbruggen en je tot de dood te verwarren, zullen we je basis overlevingspakket bespreken en proberen het grotere geheel te schilderen. We zullen het "Hoe?" Nogal omslachtig bespreken om onderweg geen nieuwe codeurs te verliezen. Het tweede deel van de vergelijking zal het "Waarom?" Uitleggen.
Als ik geluk heb, kom je weg met een goede basis voor geavanceerdere boeken, terwijl je je zeker voelt over het grotere geheel. Oké, laten we de wandeling lopen!
Laten we teruggaan naar het doel van testen. Is testen nuttig voor het schrijven van apps van betere kwaliteit? Nou, dit kan heftig worden besproken, maar op het moment dat ik deze vraag zou beantwoorden met een ja-ik ben in het hippe TDD-kamp, denk ik. Laten we eens kijken waarom tests uw apps een paar voordelen bieden die moeilijk te negeren zijn:
Ze controleren of uw werk functioneert zoals bedoeld. Voortdurend valideren dat je code schrijft die werkt, is essentieel voor de gezondheid van je applicatie en de gezondheid van je team.
Ze testen dingen die je niet met de hand wilt testen, vervelende controles die je met de hand zou kunnen doen, vooral wanneer je dit de hele tijd zou moeten controleren. U wilt zo zeker mogelijk zijn dat uw nieuwe functie of uw nieuwe klas of wat dan ook geen bijwerkingen veroorzaakt in mogelijk volledig onvoorziene delen van uw app. Door dat soort dingen te automatiseren, bespaart u niet alleen een ton van tijd, maar zullen testscenario's ook consistent en reproduceerbaar maken. Dat alleen al maakt ze veel betrouwbaarder dan foutgevoelige testen met de hand.
We willen ervoor zorgen dat de app zich op een bepaalde manier gedraagt, op een verwachte manier. Tests kunnen er in hoge mate voor zorgen dat de manier waarop gebruikers omgaan met uw app werkt en bugscenario's vermijdt die u kon zien. Tests controleren of uw toepassing werkt zoals u deze hebt ontworpen - en dat deze blijft werken nadat u wijzigingen hebt aangebracht. Dit is vooral belangrijk wanneer uw testsuite u informeert over mislukte scenario's over implementaties van uw app die mogelijk oud zijn en daarom niet meer helemaal achter in uw brein staan en niet worden overwogen terwijl u een aantal nieuwe functies introduceerde. Kortom, het helpt om uw app gezond te houden en vermijdt het introduceren van tonnen bugs.
Door tests te automatiseren, test u vaker. Stel je voor dat je om de een of andere reden voor de 40ste keer iets moet testen. Als het maar een beetje tijdrovend is, hoe gemakkelijk zal het dan zijn om je te vervelen en het proces helemaal overslaan? Dit soort dingen zijn de eerste stap op een glibberige helling waar je een fatsoenlijk percentage van de codedekking kunt vaarwel kussen.
Tests werken als documentatie. Huh? De specificaties die u schrijft, geven andere mensen in uw teams een snel toegangspunt om een nieuwe codebasis te leren en te begrijpen wat het moet doen. Het schrijven van je code in RSpec is bijvoorbeeld erg expressief en vormt zeer leesbare codeblokken die een verhaal vertellen als het goed wordt gedaan. Omdat het zeer beschrijvend kan worden geschreven, terwijl het ook een zeer beknopte Domain Specific Language (DSL) is, raakt RSpec twee vliegen in één klap: niet uitgebreid in de API en biedt het u alle middelen om zeer begrijpelijke testscenario's te schrijven. Dat is wat ik altijd leuk vond en waarom ik nooit echt warm ben geworden met Cucumber, dat hetzelfde probleem op een al te klantvriendelijke manier aan het oplossen was, denk ik.
Ze kunnen de hoeveelheid code die u schrijft minimaliseren. In plaats van rond te struinen als een gek, het uitproberen van meer freestyle, laat de praktijk van het testen van je code je alleen de code schrijven die nodig is om je tests te halen. Geen overtollige code. Wat je in je toekomstige carrière vaak zult horen, is dat de beste code code is die je niet hoeft te schrijven of zoiets. Waarom? Welnu, meestal bevatten elegantere oplossingen kleinere hoeveelheden code en ook, code die u niet schrijft - wat misschien niet nodig is - veroorzaakt geen toekomstige bugs en hoeft niet te worden onderhouden. Dus het schrijven van de tests, voordat je de implementatie schrijft, geeft je een duidelijke focus op welk probleem je vervolgens moet oplossen. Alleen het schrijven van code die nodig is, en niet per ongeluk meer, is misschien een onderschat neveneffect dat TDD je kan bieden.
Ze hebben een positief effect op uw ontwerp. Voor mij betekende het begrijpen van dit onderdeel een gloeilamp en maakte ik het hele testgedrag heel erg op prijs gesteld. Wanneer u uw implementaties rond zeer gerichte testscenario's schrijft, zal uw code hoogstwaarschijnlijk veel meer in compartimenten en modulair zijn. Omdat we allemaal vrienden van DRY zijn - "Do not repeat yourself!" - en zo min mogelijk koppeling tussen componenten in je app, is dit een eenvoudige maar effectieve discipline om systemen te realiseren die van de grond af zijn ontworpen. Dit aspect is het belangrijkste voordeel, denk ik. Ja, de andere zijn ook behoorlijk goed, maar wanneer tests ook resulteren in apps waarvan de kwaliteit beter is vanwege een verfijnd ontwerp, zou ik Jackpot zeggen!
Het komt ook neer op geld. Wanneer u een stabiele app hebt die gemakkelijk te onderhouden en eenvoudig te veranderen is, bespaart u op de lange termijn behoorlijk wat geld. Onnodige complexiteit kan projecten gemakkelijk achtervolgen, en de motivatie zal niet op een nieuw hoogtepunt zijn wanneer uw team uw code moet bestrijden omdat het broos en slecht ontworpen is. Een goed toepassingsontwerp kan uw bedrijfsdoelen absoluut ondersteunen - en omgekeerd. Wil je een aantal nieuwe functies introduceren die cruciaal zijn voor je bedrijf, maar je vecht constant tegen je architectuur omdat deze op zand is gebouwd? Natuurlijk niet, en we hebben allemaal veel voorbeelden gezien van bedrijven die om die reden snel zijn verdwenen. Goede testgewoonten kunnen een effectieve verdedigingslinie zijn voor dergelijke situaties.
Een ander doel dat belangrijk is, is met betrekking tot de kwaliteit van uw code zelf. De software die u schrijft, moet voor andere ontwikkelaars gemakkelijk te begrijpen zijn - in de mate van het mogelijke, tenminste. Uw tests kunnen echt helpen om de functionaliteit en intentie van uw toepassing over te brengen - en niet alleen voor andere leden in een team, maar ook voor uw toekomstige zelf. Als je een bepaald deel van je code een tijdje niet aanraakt, is het echt handig om je geheugen op te frissen van hoe en waarom je een stukje software hebt geschreven met de documentatie die een tool zoals RSpec biedt - en RSpec doet dat dit is echt goed, uitzonderlijk eigenlijk.
Aangezien uw code altijd zal veranderen, zal het refactoren van uw code altijd deel uitmaken van de ontwikkeling van uw software. En aangezien veranderingen zo in dit proces worden ingebakken, moet u ervoor zorgen dat deze wijzigingen op onverwachte plaatsen geen onverwachte neveneffecten genereren. De testsuite geeft je een mooi hechtend veiligheidsnet om je comfortabeler en vrijer te voelen om met plezier te refacteren. Dit aspect, naast de ontwerpvoordelen die TDD je kan bieden, is mijn favoriete voordeel waar een testsuite je mee kan helpen. Het wijzigen en uitbreiden van uw code is zo'n essentieel onderdeel van het innoveren van uw reeds uitgebrachte "product" dat u een tool nodig heeft die u zoveel mogelijk vrijheid biedt bij dat proces. Ik weet niet zeker of mensen die kritisch zijn over het schrijven van een uitgebreide testsuite zich veel zorgen maken over dit aspect.
Je hebt een goede kans om nieuwe dingen sneller te bouwen in latere stadia omdat de feedback van de testsuite je feedback geeft over je fouten, bugs en beperkingen - veel sneller dan een mens kan testen, natuurlijk. Bovendien geeft het u het vertrouwen dat u werkt met een beveiligingsnet dat des te langer waardevol wordt naarmate u verder gaat.
In uw apps, vooral als deze aanzienlijk zijn gegroeid, wilt u op uw software kunnen vertrouwen. 100% code dekking klinkt een stuk zoeter als je een site hebt die een paar jaar oud is en aangeraakt door honderden ontwikkelaars. Vertrouwen in de nieuwe code die je introduceert en daarop voortbouwen is een van de wezens van softwareontwikkeling die geld later niet meer kan kopen.
rails nieuw your_app -T
-T kunt u Testeenheid overslaan, het testraamwerk dat met Rails wordt meegeleverd.
groep: ontwikkeling,: test do edel 'rspec-rails' einde
bundel
Daarna moeten we een generator draaien die wordt geleverd met RSpec:
rails genereren van rspec: installeren
create .rspec create spec create spec / spec_helper.rb create spec / rails_helper.rb
Wat dit doet, is de basisstructuur voor uw RSpec-tests in Rails instellen. Zoals je kunt zien aan de uitgang hierboven, heeft deze generator een a geïnitialiseerd spec map met een paar bestanden die je later nodig hebt. De .rspec bestand is een configuratiebestand dat we voorlopig niet hoeven te manipuleren. Ik wilde je even laten weten wat je voor je hebt. De andere bestanden spreken voor zich, maar ik wilde hun verschillen vermelden.
Accentsconagua
spec_helper.rb is voor specificaties die niet afhankelijk zijn van Rails.rails_helper.rb, aan de andere kant, is voor specs die er wel afhankelijk van zijn.Wat niet voor de hand ligt, is dat een van deze bestanden bovenop uw spec-bestanden (testbestanden) moet worden geplaatst om uw tests uit te voeren. Laten we snel kijken! Wanneer u een model genereert via:
rails genereren model dummy_model naam: string
active_record aanroepen create db / migrate / 20160521004127_create_dummy_models.rb create app / models / dummy_model.rb create rspec create spec / models / dummy_model_spec.rb
Rails hebben niet alleen de bijbehorende gemaakt _spec.rb bestanden voor u, uw specs zullen ook automatisch hebben vereisen 'rails_helper' standaard bovenop uw spec-bestanden. Dat betekent dat je meteen klaar bent om te gaan.
vereisen 'rails_helper' ...
Met deze opstelling kunt u uw Rails-app testen, bijvoorbeeld uw modellen, en RSpec zal niet in de war raken over de modelklassen die in Rails worden gebruikt. Dit is nodig om te eisen wanneer je dingen zoals nodig hebt ActiveRecord, ApplicationController enzovoorts. Dit is dus je normale scenario en daarom zou dit je eerste logische keuze moeten zijn als beginner.
vereisen spec_helper.rb, aan de andere kant, zal een fout slaan als je tests schrijft die bedrijfslogica van je Rails-app bevatten. In dat scenario zou RSpec niet weten waar je het over hebt als je bijvoorbeeld een Rails-model wilt testen.
Zo lang verhaal superkort, spec_helper laadt geen Rails - dat is alles! Natuurlijk kun je los gaan met configuraties, maar dit is niets waar ik me nu zorgen over wil maken. Laten we ons concentreren op de basisprincipes, het uitvoeren van tests en de syntaxis. Dat zou moeten volstaan voor starters. Laten we verder gaan!
U bent klaar om uw tests uit te voeren. RSpec vereist dat uw testbestanden een specifiek achtervoegsel hebben zoals _spec om te begrijpen welke bestanden moeten worden uitgevoerd. Als u een generator gebruikt, is dit geen zorg, maar als u zelf testbestanden wilt schrijven, moet dit zo zijn. U moet dus een bestand plaatsen zoals your_first_test_spec.rb in uw spec directory.
Het gebruik van de generator voor het maken van een dummy-model heeft ons al voorzien spec / modellen / dummy_model_spec.rb. Niet slecht! Nog één ding te doen voordat de tests klaar zijn:
rake db: migreer rake db: test: bereid je voor
Deze opdrachten voeren uw migratie uit voor het dummy-model dat we hierboven hebben gegenereerd en stellen ook de testdatabase samen met dat model. Nu voeren we de test uit:
hark
De hark commando voert al uw tests uit, de complete testsuite. Normaal gesproken zou u deze opdracht moeten gebruiken als u een functie hebt voltooid en de hele testsuite wilt oefenen.
* In behandeling: (Fouten die hier worden vermeld, worden verwacht en hebben geen invloed op de status van uw suite) 1) DummyModel voegt enkele voorbeelden toe aan (of verwijdert) / Users / vis_kid / projects / rspec-test-app / rspec-dummy / spec / models / dummy_model_spec .rb # Nog niet geïmplementeerd # ./spec/models/dummy_model_spec.rb:4 Voltooid in 0.00083 seconden (bestanden duurden 1,94 seconden om te laden) 1 voorbeeld, 0 storingen, 1 in afwachting
Gefeliciteerd! U hebt net uw eerste RSpec-test uitgevoerd. Niet zo erg, toch? Dit was natuurlijk een dummy test voor nu - met dummy testcode gegenereerd door Rails. De meer gerichte versie van het uitvoeren van uw tests - u hebt eigenlijk veel meer opties dan alleen dat - is om een afzonderlijk bestand uit te voeren, bijvoorbeeld. Zoals dit:
bundel exec rspec spec / models / dummy_model_spec.rb
Dit zal alleen een enkel testbestand uitvoeren in plaats van het hele testsuite. Met grotere applicaties die afhankelijk zijn van een groot aantal testbestanden, wordt dit een real-time saver. Maar in termen van tijdsbesparing en testspecificiteit, is dit slechts oppervlakkig aan het oppervlak, om eerlijk te zijn. Ik denk dat we tijdens het testen in het derde artikel in deze serie meer zullen afleggen hoe we een aanzienlijke hoeveelheid tijd moeten scheren. Laten we kijken hoe ver we komen!
De andere manier om de hele testsuite uit te oefenen, is door gewoon te lopen rspec-met of zonder bundel exec, afhankelijk van je opstelling.
bundel exec rspec
Nog een ding dat ik moet noemen voordat we verder gaan, je kunt ook alleen een specifieke subset van tests uitvoeren. Stel dat u alleen al uw tests wilt uitvoeren voor uw modelcode:
bundel exec rspec spec / modellen
Zo eenvoudig!
Ik raad aan om te beginnen met de basisbegrippen en enkele opties te bekijken die RSpec biedt in de volgende twee artikelen. Laten we eens kijken naar de basisstructuur van een test en duiken in meer geavanceerd water wanneer we deze uit de weg hebben geruimd.
beschrijvenDit wordt je brood en boter omdat het je specificaties organiseert. U kunt zelf naar reeksen of klassen verwijzen:
beschrijven Gebruiker do end beschrijven 'Sommige string' do end
beschrijven secties zijn de basisbouwstenen om uw tests te organiseren in logische, samenhangende groepen om te testen. Kortom, een scope voor verschillende delen van uw applicatie die u wilt testen.
beschrijven Gebruiker do ... einde beschrijven Gast doen ... einde beschrijven Aanvaller do ... einde
Een goede tip is om je bereik nog meer aan te scherpen. Omdat sommige klassen behoorlijk zullen groeien, is het geen goed idee om alle methoden die je wilt testen voor één klas in een single te hebben beschrijven blok. Je kunt natuurlijk meerdere van deze blokken maken en ze in plaats daarvan richten op instantie of klassemethoden. Om uw intentie duidelijker te maken, volstaat het om de klassenaam een extra tekenreeks te geven die verwijst naar de methode die u wilt testen.
beschrijven Agent, '#favorite_gadget' do ... end beschrijven Agent, '#favorite_gun' do ... end beschrijven Agent, '.gambler' do ... end
Op die manier krijg je het beste van beide werelden. Je kapselt gerelateerde tests in hun representatieve groepen in, terwijl je de dingen geconcentreerd houdt en op een fatsoenlijke grootte houdt. Voor gebruikers die erg nieuw zijn in Ruby land, zou ik dat moeten noemen # refereert eenvoudigweg naar een instantiemethode terwijl de punt . is gereserveerd voor klassemethoden. Omdat ze binnen de reeksen zitten, hebben ze hier geen technische implicaties, maar ze geven je intentie aan aan andere ontwikkelaars en je toekomstige zelf. Vergeet niet de komma achter de naam van de klas - hij werkt niet zonder deze naam! Binnen een minuut, wanneer we aankomen verwachten, Ik zal je laten zien waarom deze aanpak superhandig is.
hetBinnen het bereik van beschrijven groepen gebruiken we een ander bereik van het blokken. Deze zijn gemaakt voor de daadwerkelijke voorbeelden die worden getest. Als u de instantiemethode wilt testen #favorite_gadget op de Middel klasse, zou het er zo uitzien:
beschrijf Agent, '#favorite_gadget' do it 'retourneert een item, het favoriete gadget van de agent' do ... end end
De tekenreeks die u aan de het block werkt als de belangrijkste documentatie voor uw test. Daarin specificeer je precies welk gedrag je wilt of verwacht van de methode in kwestie. Mijn aanbeveling is niet overboord te gaan en er te veel over te zeggen, maar tegelijkertijd niet overdreven cryptisch te zijn en anderen te verwarren met overdreven slimme beschrijvingen..
Denk na over wat de kleinste en eenvoudigste implementatie van dit deel van de puzzel kan en zou moeten bereiken. Hoe beter u dit deel schrijft, hoe beter de algemene documentatie voor uw app zal zijn. Haast je niet over dit deel, want het is gewoon een touwtje dat geen schade kan aanrichten - tenminste niet op het oppervlak.
verwachten()Nu komen we meer tot de kern van dingen. Met deze methode kunt u het gedeelte van het systeem dat u wilt testen, verifiëren of vervalsen. Laten we teruggaan naar ons vorige voorbeeld en het bekijken in (beperkte) actie:
omschrijf Agent, '#favorite_gadget' do it 'retourneert een item, het favoriete gadget van de agent' verwacht wel (agent.favorite_gadget) .naar het einde van 'Walther PPK'
verwachten() is de "nieuwe" assertiesyntaxis van RSpec. Eerder gebruikten we moeten in plaats daarvan. Een ander verhaal, maar ik wilde het vermelden voor het geval je het tegenkomt. verwachten() verwacht dat je het een object geeft en oefent elke testmethode erop uit. Ten slotte schrijf je de beweerde uitkomst aan de rechterkant.
Je hebt de mogelijkheid om met de positieve of negatieve route te gaan .tot eq of .not_to eq bijvoorbeeld (eq een tekort aan natuurlijk natuurlijk). U kunt de logica altijd omdraaien, wat u het beste past. Laten we deze onzinnige test uitvoeren en ons concentreren op de uitvoer die we hebben gekregen als resultaat van onze testopstelling:
rspec spec / models / agent_spec.rb
Fouten: 1) Agent # favorite_gadget retourneert een item, het favoriete gadget van de agent Fout / Fout: verwacht (agent.favorite_gadget) .naar 'Walther PPK'.
Leest best aardig, toch?? ** "Agent # favorite_gadget retourneert een item en de favoriete gadget van de middel"** vertelt je alles wat je moet weten:
Als we de reeks die de methode in de beschrijven blok, dan zou de uitvoer veel minder duidelijk en leesbaar zijn geweest:
beschrijven Agent doe het 'geeft als resultaat één item, de favoriete gadget van de agent' verwacht (agent.favorite_gadget) .naar het einde van 'Walther PPK'
Fouten: 1) Agent retourneert een item, de favoriete gadget van de agent Fout / Fout: verwacht (agent.favorite_gadget) .naar 'Walther PPK'.
Natuurlijk zijn er andere manieren om dit te omzeilen en hiermee om te gaan - deze informatie doorgeven via uw het blokkeren, bijvoorbeeld, maar de andere benadering is eenvoudig en werkt. Wat je bloed ook doet stromen, natuurlijk!
De beste werkwijzen bij het testen bevelen aan dat we onze tests in vier verschillende fasen samenstellen:
Deze vier fasen zijn vooral bedoeld voor leesbaarheid en om uw tests een conventionele structuur te geven. Het is een zogenaamd testpatroon, eigenlijk een praktijk waarvan de gemeenschap het erover eens was dat het nuttig en aanbevolen was. Dit hele patronenonderwerp is een diep konijnenhol, dus weet dat ik een bosje zal weglaten om de beginners niet tot de dood te verwarren.
Tijdens de installatie bereidt u het scenario voor waaronder de test moet worden uitgevoerd. In de meeste gevallen bevat dit gegevens die nodig zijn voor een soort oefening. Kleine tip: maak dingen niet te ingewikkeld en stel alleen de minimale hoeveelheid in die nodig is om de test te laten werken.
agent = Agent.create (naam: 'James Bond') missie = Mission.create (naam: 'Moonraker', status: 'Briefed')
Dit onderdeel geeft precies het ding weer dat je in deze specificatie wilt testen. Kan zo simpel zijn als:
status = mission.agent_status
Nu verifieert u of uw bewering over de test wordt voldaan of niet. U test het systeem dus aan uw eigen verwachtingen.
verwacht (status) .not_to eq 'MIA')
Het framework zorgt voor problemen met het geheugen en de database-reiniging - in feite een reset. U kunt op dit moment niets regelen. Het doel is om een ongerepte staat terug te krijgen om nieuwe tests uit te voeren zonder verrassingen van de op dat moment lopende tests. Laten we eens kijken wat dit zou betekenen in een dummy-voorbeeld:
omschrijf Agent, '#favorite_gadget' do it 'retourneert een item, het favoriete gadget van de agent' do # Setup agent = Agent.create (naam: 'James Bond') q = Quartermaster.create (naam: 'Q') q .technical_briefing (agent) # Oefening favorite_gadget = agent.favorite_gadget # Verifiëren verwachten (favoriet_gadget) .naar 'Walther PPK'. # Teardown wordt nu grotendeels afgehandeld door RSpec zelf end-end
Zoals je ziet, hebben we in dit voorbeeld de oefening en de fases duidelijk van elkaar gescheiden, terwijl we in de andere dummy-voorbeelden hierboven, verwacht (agent.favorite_gadget). om 'Walther PKK' te gebruiken, we hebben beide fasen samen gemengd. Beide zijn geldige scenario's en hebben hun plaats. Ook helpen de nieuwe regels om visueel te scheiden hoe de test is gestructureerd.
Nu komt het moeilijke deel, wat te testen en hoe. Naar mijn mening is dit het aspect van testen dat voor nieuwkomers het meest verwarrend is - en begrijpelijkerwijs! Je bent nieuw in de taal en het kader en weet vaak nog niet eens wat je niet weet. Hoe schrijf je daar tests voor? Zeer goede vraag.
Ik zal heel openhartig zijn, waarschijnlijk niet - en dat zul je een hele tijd niet doen. Het duurt even om vertrouwd te raken met dit spul. Als je een mentor hebt of naar een of ander bootkamp gaat, heb je de mogelijkheid om direct te leren van ervaren mensen. In dat geval zal uw voortgang op deze afdeling natuurlijk anders zijn.
Aan de andere kant, als - zoals zoveel anderen daarbuiten - je jezelf dit spul leert, zal geduld de sleutel zijn. Als je alle boeken en artikelen leest, kom je zeker in de goede richting, maar ik denk dat testen veel meer geavanceerde puzzelstukken nodig heeft om volledig te begrijpen en, misschien nog belangrijker, voordat je je er prettig bij voelt..
Het "goede" nieuws is dat dit niet ongebruikelijk is en dat we er allemaal zijn geweest. Doorzettingsvermogen is belangrijk. Je kunt dit doen, het is geen rocket science, maar het zal een tijdje duren voordat je een applicatie effectief kunt schrijven van de andere kant op - vanuit het perspectief van tests, bedoel ik. Voor nu, blijf duwen, veel plezier hebben, fouten maken, apps schrijven, tutorials kopiëren en zo verder, totdat de lamp uitgaat.
Wanneer u uw individuele tests schrijft, wilt u dat hun objecten het eenvoudigst doen wat u kunt om uw doel te bereiken: zeer gerichte tests zijn echt van groot belang. U wilt uw toepassing via zeer eenvoudige stappen ontwerpen en vervolgens de fouten volgen die uw testsuite u biedt.
Implementeer alleen wat nodig is om de app groen te maken. Niet meer, niet minder! Dat is het "gedreven" deel in testgestuurde ontwikkeling. Uw werk wordt gestuurd door de behoeften van uw tests.
