Share
In dit laatste artikel over de basisprincipes van RSpec bespreken we enkele dubieuze onderdelen die u kunt en moet vermijden, hoe u uw tests moet samenstellen, waarom u de database zo veel mogelijk moet vermijden en hoe u uw testsuite kunt versnellen..
Nu dat je de basis hebt, zouden we de tijd moeten nemen om een paar dubieuze delen van RSpec en TDD te bespreken - een paar problemen die gemakkelijk kunnen worden overgebruikt en sommige nadelen van het gebruik van delen van RSPec's DSL niet-gereflecteerd. Ik wil vermijden veel geavanceerde concepten in je pas gearceerde TDD-hersenen te stoppen, maar ik heb het gevoel dat er een paar punten moeten worden gemaakt voordat je je eerste testvlucht maakt. Ook het creëren van een langzame testsuite als gevolg van slechte gewoonten die gemakkelijk te vermijden zijn, kan je meteen als beginner verbeteren.
Natuurlijk zijn er nogal wat dingen die je nodig hebt om meer ervaring op te doen voordat je je comfortabel en effectief voelt met het testen, maar ik wed dat je je ook meteen beter zult voelen als je een paar van de best practices weghaalt die je verbeteren specs spruitstuk zonder je vaardigheden nu al te veel uit te rekken. Het is ook een klein venster op geavanceerdere concepten die u in de loop van de tijd zult moeten oppikken om het testen te "beheersen". Ik heb het gevoel dat ik je in het begin niet te veel lastig moet vallen, omdat het misschien ingewikkeld en verwarrend kan zijn voordat je het grotere plaatje hebt ontwikkeld dat alles netjes met elkaar verbindt.
Laten we beginnen met snelheid. Een snelle suite is niets dat per ongeluk gebeurt; het is een kwestie van "constant" onderhoud. Luisteren naar je tests is erg belangrijk - tenminste als je aan boord bent met TDD en de Kool-Aid een tijdje hebt gedronken - en snelle testsuites maken het veel redelijker om aandacht te schenken aan waar de tests leiden u.
De testsnelheid is iets waar u goed voor moet zorgen. Het is essentieel om het testen van een normale gewoonte te maken en het leuk te houden. U wilt uw tests snel kunnen uitvoeren, zodat u tijdens het ontwikkelen snel feedback krijgt. Hoe langer het duurt om de testsuite uit te oefenen, des te groter de kans dat u meer en meer test totdat u het pas aan het einde doet voordat u een nieuwe functie wilt verzenden.
In het begin klinkt dat misschien niet zo slecht, maar dit is geen triviaal probleem. Een van de belangrijkste voordelen van een testsuite is dat deze het ontwerp van uw toepassing begeleidt - voor mij is dit waarschijnlijk de grootste overwinning van TDD. Langere testritten maken dit onderdeel vrijwel onmogelijk omdat het zeer waarschijnlijk is dat u ze niet zult uitvoeren om uw flow niet te breken. Snelle tests garanderen dat u geen reden hebt om uw tests niet uit te voeren.
U kunt dit proces zien als een dialoog tussen u en de testsuite. Als dit gesprek te langzaam wordt, is het erg pijnlijk om door te gaan. Wanneer uw coderedacteur de mogelijkheid biedt om ook uw tests uit te voeren, moet u deze functie zeker gebruiken. Dit zal de snelheid drastisch verhogen en uw workflow verbeteren. Schakelen tussen je editor en een shell om je tests uit te voeren, wordt snel oud. Maar aangezien deze artikelen zijn gericht op newbie-programmeurs, verwacht ik niet dat je dit soort tools meteen zo instelt. Er zijn andere manieren om dit proces te verbeteren zonder meteen met je editor te hoeven sleutelen. Het is echter goed om te weten en ik raad aan dergelijke hulpmiddelen deel te laten uitmaken van uw workflow.
Houd er ook rekening mee dat u al hebt geleerd hoe u uw tests moet afsnijden en dat u niet de hele testreeks hoeft uit te voeren. U kunt eenvoudig afzonderlijke of zelfs enkele bestanden uitvoeren het blokken-alles binnen een capabele code-editor zonder het ooit te verlaten voor de terminal. U kunt de test bijvoorbeeld concentreren op de te testen lijn. Dat voelt als magie, om eerlijk te zijn - het wordt nooit saai.
Te veel schrijven naar de database, vaak erg onnodig, is een zekere manier om uw testsuite aanzienlijk te vertragen. In veel testscenario's kunt u de gegevens wissen die u nodig hebt om een test in te stellen en zich te concentreren op de gegevens die direct worden getest. U hoeft het grootste deel van de tijd niet in de database te raken, vooral niet voor onderdelen die niet rechtstreeks worden getest en alleen de test op de een of andere manier ondersteunen: een ingelogde gebruiker terwijl u het te betalen bedrag test op een afrekenen, bijvoorbeeld. De gebruiker is als een extra die kan worden uit beeld gebracht.
Je moet proberen weg te komen door niet zo veel mogelijk de database te raken omdat dit een groot deel van een trage testsuite bijt. Probeer ook niet te veel gegevens in te stellen als je het helemaal niet nodig hebt. Dat kan heel eenvoudig vergeten worden met integratietests in het bijzonder. Unit-testen zijn vaak veel meer gefocust op definitie. Deze strategie zal zeer effectief zijn in het voorkomen van het vertragen van testsuites in de loop van de tijd. Kies uw afhankelijkheden met de grootste zorg en kijk wat de kleinste hoeveelheid gegevens is waarmee uw tests slagen.
Ik wil nu niet verder ingaan op de details - het is waarschijnlijk een beetje te vroeg in je traject om te praten over stompjes, spionnen, namaakgoederen en zo. Je hier verwarren met zulke geavanceerde concepten lijkt contraproductief en je zult ze snel genoeg tegenkomen. Er zijn veel strategieën voor snelle tests waarbij ook andere hulpmiddelen zijn betrokken dan RSpec. Probeer voorlopig je hoofd rond het grotere geheel te wikkelen met RSpec en testen in het algemeen.
Je wilt ook proberen alles maar één keer te testen, als het kan. Test niet steeds hetzelfde opnieuw, dat is gewoon verspilling. Dit gebeurt meestal door per ongeluk en / of slechte ontwerpbeslissingen. Als je begint met langzame tests, is dit een eenvoudige plek om te refactoren om een snelheidsboost te krijgen.
Het merendeel van uw tests moet ook op het niveau van de unit zijn en uw modellen testen. Dit zal niet alleen de dingen snel houden, maar zal je ook de grootste waar voor je geld geven. Integratietests die hele werkstromen testen - het gedrag van de gebruiker tot op zekere hoogte imiteren door een aantal componenten bij elkaar te brengen en deze synchroon te testen - moeten het kleinste deel van uw testpiramide zijn. Deze zijn nogal traag en "duur". Misschien is 10% van je algehele tests niet onrealistisch om op te schieten, maar dit hangt ervan af, denk ik.
Het kan moeilijk zijn om de database zo weinig mogelijk uit te oefenen, omdat je nog veel meer tools en technieken moet leren om dit effectief te bereiken, maar het is essentieel om testsuites te laten groeien die redelijk snel genoeg zijn om je tests regelmatig uit te voeren.
De Spring-server is een functie van Rails en laadt uw applicatie vooraf. Dit is een andere eenvoudige strategie om uw testsnelheid aanzienlijk te verhogen - direct uit de doos, zou ik moeten toevoegen. Wat het doet, is gewoon uw applicatie op de achtergrond laten draaien zonder dat u deze hoeft te booten met elke afzonderlijke testrun. Hetzelfde geldt voor Rake-taken en -migraties; deze zullen ook sneller lopen.
Sinds Rails 4.1 is Spring opgenomen in Rails - automatisch toegevoegd aan de Gemfile - en u hoeft niet veel te doen om deze preloader te starten of te stoppen. In het verleden moesten we daarvoor onze eigen tools naar keuze inpluggen - wat je natuurlijk nog steeds kunt doen als je andere voorkeuren hebt. Wat echt heel leuk en attent is, is dat het automatisch opnieuw wordt opgestart als je enkele edelstenen, initializers of configuratiebestanden verandert - een leuke en handige manier, omdat je gemakkelijk vergeet om er zelf voor te zorgen.
Standaard is deze geconfigureerd om te worden uitgevoerd rails en hark alleen opdrachten. Dus we moeten het instellen om ook met de te werken rspec opdracht voor het uitvoeren van onze tests. Je kunt de status van de lente vragen zoals:
lente status
De lente loopt niet.
Omdat de output ons vertelde dat Spring niet draait, start je het gewoon met lente server. Wanneer je nu rent lente status, je zou iets moeten zien dat er ongeveer zo uitziet:
De lente is in bedrijf: 3738 lente server | rspec-dummy | 21 seconden geleden begonnen
Nu moeten we controleren wat Spring is ingesteld om te laden.
lente binstub - alles
* bak / hark: veer al aanwezig * bak / rails: veer al aanwezig
Dit vertelt ons dat Spring Rails vooraf installeert hark en rails opdrachten, en verder niets. Dat we moeten zorgen. We moeten de edelsteen toevoegen lente-commando-rspec, en onze tests zijn dan klaar om te worden voorgeladen.
gem 'spring-commands-rspec', groep:: ontwikkeling
bundel installeer bundel exec spring binstub rspec
Ik bespaar je de uitvoer van bundel installeren; Ik ben er zeker van dat je meer dan je eerlijke deel al hebt gezien. hardlopen bundel exec voorjaar binstub rspec, aan de andere kant genereert een bin / rspec bestand dat in principe toevoegt dat het door Spring is voorgeladen. Laten we kijken of dit werkte:
lente binstub - alles
Dit creëerde iets genaamd een binstub-een wrapper voor executables zoals rails, hark, bundel, rspec en zodanig dat wanneer u de rspec opdracht dat het Spring gebruikt. Terzijde: dergelijke binstubs zorgen ervoor dat u deze uitvoerbare bestanden in de juiste omgeving uitvoert. Ze laten je deze opdrachten ook uitvoeren vanuit elke directory in je app, niet alleen vanuit de root. Het andere voordeel van binstubs is dat u niet hoeft vooraf te gaan bundel exec met alles.
* bak / hark: veer al aanwezig * bak / rspec: veer al aanwezig * bak / rails: veer al aanwezig
Ziet er goed uit! Laten we de Spring-server stoppen en opnieuw starten voordat we verder gaan:
veerstop veer server
Dus nu voer je de lenteserver uit in een speciaal terminalvenster en voer je tests uit met een iets andere syntaxis in een andere. We moeten gewoon elke testrun prefixen met de de lente commando:
veer rspec spec
Dit voert natuurlijk al je spec-bestanden uit. Maar het is niet nodig om daar te stoppen. U kunt ook afzonderlijke bestanden of gelabelde tests uitvoeren via Spring-no problem! En ze zullen nu allemaal razendsnel zijn; op kleinere testsuites lijken ze bijna ogenblikkelijk. Bovendien kunt u dezelfde syntaxis gebruiken voor uw rails en hark commando's. Leuk, eh?
veerhark veerrails g model BondGirl naam: snaar veerhark db: trek ...
Dus we krijgen Spring uit de doos om dingen in Rails te versnellen, maar we moeten niet vergeten dit kleine juweeltje toe te voegen om Spring te laten weten hoe hij een bal moet spelen met RSpec.
De dingen die in dit gedeelte worden genoemd, zijn waarschijnlijk goed om te voorkomen, zolang u maar een andere oplossing voor hen kunt vinden. Het overmatig gebruik van een paar van de RSpec-gemakken kan leiden tot het ontwikkelen van slechte testgewoonten - op zijn minst dubieuze. Wat we hier zullen bespreken is handig aan de oppervlakte, maar kan je een beetje later op de weg bijten.
Ze moeten niet als AntiPatterns worden beschouwd - dingen die je meteen moet vermijden - maar eerder worden gezien als 'geuren', dingen waar je voorzichtig mee moet zijn en die aanzienlijke kosten met zich meebrengen die je vaak niet wilt betalen. De reden hiervoor is dat je nog een paar ideeën en concepten hebt waarvan je als beginneling waarschijnlijk nog niet vertrouwd bent - en eerlijk gezegd misschien nog een beetje over je hoofd - maar ik zou je op zijn minst een paar uur naar huis moeten sturen rode vlaggen om voor nu te bedenken en vast te leggen.
Accentsconagua
laatVeel hebben laat referenties lijken in het begin erg handig, vooral omdat ze de dingen behoorlijk DROOG maken. Het lijkt in eerste instantie een redelijk goede extractie om ze bovenaan je bestanden te hebben, bijvoorbeeld. Aan de andere kant kunnen ze je gemakkelijk de tijd geven om je eigen code te begrijpen als je bepaalde tests later een aanzienlijke hoeveelheid tijd later bezoekt. De gegevens niet instellen in uw laat blokken helpt niet om je tests te goed te begrijpen. Dat is niet zo triviaal als het eerst klinkt, vooral als er andere ontwikkelaars bij betrokken zijn die ook je werk moeten lezen.
Dit soort verwarring wordt een stuk duurder naarmate er meer ontwikkelaars bij betrokken zijn. Het is niet alleen tijdrovend als je moet jagen laat referenties over en weer, het is ook dom omdat het met zeer weinig moeite vermeden kon worden. Duidelijkheid is koning, geen twijfel mogelijk. Een ander argument om deze gegevens inline te houden, is dat uw testsuite minder broos zal zijn. Je wilt geen kaartenhuis bouwen dat steeds onstabieler wordt laat dat verbergt details van elke test. U hebt waarschijnlijk geleerd dat het gebruik van globale variabelen geen goed idee is. Op die manier, laat is semi-globaal binnen uw spec-bestanden.
Een ander probleem is dat je veel verschillende varianten, verschillende toestanden voor vergelijkbare scenario's moet testen. Je zult snel opraken van redelijk benoemde laat uitspraken om alle verschillende versies te dekken die je misschien nodig hebt - of eindigen met een hooiberg van tonnen gelijkaardige staatsvariaties. Wanneer u de gegevens direct in elke test opslaat, hebt u dat probleem niet. Lokale variabelen zijn goedkoop, goed leesbaar en knoeien niet met andere scopes. Sterker nog, ze kunnen nog expressiever zijn omdat je niet hoeft te denken aan heel veel andere tests die een probleem kunnen hebben met een bepaalde naam. U wilt voorkomen dat er een nieuwe DSL wordt gemaakt bovenop het framework dat iedereen moet ontcijferen voor elke test die wordt gebruikt laat. Ik hoop dat dit heel erg op een verspilling van ieders tijd lijkt.
voor & na Spaar dingen zoals voor, na en zijn variaties voor speciale gelegenheden en gebruiken het niet altijd, overal. Zie het als een van de grote kanonnen die je uithaalt voor metamateriaal. Het opschonen van uw gegevens is een goed voorbeeld dat te veel meta is voor elke individuele test om mee om te gaan. Dat wil je natuurlijk extraheren.
Vaak zet je de laat dingen aan de bovenkant van een bestand en verberg deze details voor andere tests die ze gebruiken om door het bestand te bladeren. U wilt de relevante informatie en gegevens zo dicht mogelijk bij het onderdeel hebben waar u de test daadwerkelijk uitvoert, niet kilometers verwijderd waardoor individuele tests duisterder worden.
Op het einde voelt het als te veel touw om jezelf mee op te hangen, omdat laat introduceert veel gedeelde armaturen. Dat komt in feite neer op dummy-testgegevens waarvan de reikwijdte niet strak genoeg is.
Dit leidt gemakkelijk tot één belangrijke geur genaamd "mystery guest". Dat betekent dat u testgegevens hebt die uit het niets verschijnen of die gewoon worden aangenomen. Je zult ze vaak eerst moeten opjagen om een test te begrijpen, vooral als er enige tijd verstreken is sinds je de code hebt geschreven of als je nog niet bekend bent met een codebase. Het is veel effectiever om uw testgegevens inline precies te definiëren waar u het nodig hebt - bij het opzetten van een bepaalde test en niet in een veel breder bereik.
... beschrijven Agent, '#print_favorite_gadget' do it 'drukt de naam van de agenten af, rang en favoriete gadget' verwacht (agent.print_favorite_gadget) .to eq ('Commander Bond heeft iets met Aston Martins') eindeAls je dit bekijkt, leest het heel mooi, toch? Het is beknopt, een one-liner, redelijk schoon, nietwaar? Laten we onszelf niet voor de gek houden. Deze test vertelt ons niet veel over de middel in kwestie, en het vertelt ons niet het hele verhaal. De implementatiedetails zijn belangrijk, maar we zien er niets van. De agent lijkt ergens anders te zijn gemaakt en we moeten er eerst op jagen om volledig te begrijpen wat hier gebeurt. Dus het ziet er misschien elegant uit aan de oppervlakte, maar het komt met een flinke prijs.
Ja, je tests zullen in dat opzicht niet altijd super DROOG worden, maar dit is een kleine prijs die je moet betalen om expressiever en gemakkelijker te begrijpen te zijn, denk ik. Natuurlijk zijn er uitzonderingen, maar ze moeten echt alleen maar worden toegepast op uitzonderlijke omstandigheden nadat je de opties hebt uitgeput die pure Ruby biedt meteen.
Met een mystery guest moet je uitvinden waar data vandaan komt, waarom het ertoe doet, en wat de details zijn. Het niet zien van de implementatiedetails in een bepaalde test zelf maakt je leven alleen maar moeilijker dan het zou moeten zijn. Ik bedoel, doe waar je zin in hebt als je aan je eigen projecten werkt, maar wanneer andere ontwikkelaars erbij betrokken zijn, zou het leuker zijn om na te denken over het zo soepel mogelijk maken van hun ervaring met je code..
Zoals met veel dingen, ligt het essentiële in de details natuurlijk, en je wilt jezelf en anderen er niet in het duister over houden. Leesbaarheid, beknoptheid en het gemak van laat mag niet ten koste gaan van het verliezen van duidelijkheid over implementatiedetails en misleiding. U wilt dat elke afzonderlijke test het volledige verhaal vertelt en alle context biedt om het meteen te begrijpen.
Om een lang verhaal kort te maken, wil je testen die gemakkelijk te lezen zijn en gemakkelijker te redeneren op basis van een test per test. Probeer alles te specificeren wat je nodig hebt in de eigenlijke test - en niet meer dan dat. Dit soort afval begint net als elk ander soort rommel te "ruiken". Dat betekent ook dat u de details die u nodig hebt voor specifieke tests zo laat mogelijk moet toevoegen - wanneer u testgegevens in het algemeen maakt, in het werkelijke scenario en niet op een bepaalde plaats op afstand. Het voorgestelde gebruik van laat biedt een ander soort gemak dat dit idee lijkt tegen te werken.
Laten we het vorige voorbeeld nog een keer proberen en het implementeren zonder de mysterieuze gastkwestie. In de onderstaande oplossing vinden we alle relevante informatie voor de test inline. We kunnen precies in deze specificatie blijven als het mislukt en we hoeven niet op zoek te gaan naar aanvullende informatie ergens anders.
... beschrijf Agent, '#print_favorite_gadget' do it 'print de agenten naam, rang en favoriete gadget' do agent = Agent.new (naam: 'James Bond', rang: 'Commander', favorite_gadget: 'Aston Martin') verwacht (agent.print_favorite_gadget) .to eq ('Commander Bond heeft iets met Aston Martins') end-endHet zou fijn zijn als laat laat u barebones-testgegevens instellen die u bij elke specifieke test op need-to-know-basis zou kunnen verbeteren, maar dit is niet hoe laat rolt. Dat is hoe we tegenwoordig fabrieken gebruiken via Factory Girl.
Ik zal je de details besparen, vooral omdat ik er al een paar stukjes over heb geschreven. Hier zijn mijn newbie-tailored artikelen 101 en 201 over wat Factory Girl te bieden heeft - als je daar al nieuwsgierig naar bent. Het is geschreven voor ontwikkelaars zonder veel ervaring.
Laten we een ander eenvoudig voorbeeld bekijken dat goed gebruikmaakt van ondersteunende testgegevens die inline zijn opgezet:
beschrijf Agent, '#current_mission' do it 'drukt de huidige missiestatus en het doel van de agent uit' do mission_octopussy = Mission.new (naam: 'Octopussy', doelstelling: 'Stop bad white dude') bond = Agent.new (naam : 'James Bond', status: 'Undercover-operatie', sectie: '00', licence_to_kill: true) bond.missions << mission_octopussy expect(bond.current_mission).to eq ('Agent Bond is currently engaged in an undercover operation for mission Octopussy which aims to stop bad white dude') end endZoals je kunt zien, hebben we alle informatie die deze test nodig heeft op één plek en hoeven we geen andere plek op te zoeken. Het vertelt een verhaal en is niet obscuur. Zoals gezegd, dit is niet de beste strategie voor DRY-code. De uitbetaling is echter goed. Duidelijkheid en leesbaarheid wegen zwaarder dan dit kleine beetje herhalende code, vooral in grote codebases.
Stel dat u een nieuwe, schijnbaar niet-gerelateerde functie schrijft, en plotseling begint deze test te mislukken als onderpandschade en hebt u dit specificatiebestand niet in alle leeftijden aangeraakt.
Denk je dat je blij zult zijn als je de installatiecomponenten eerst moet ontcijferen om deze falende test te begrijpen en op te lossen voordat je verder kunt gaan met een heel andere functie waar je aan werkt? Ik denk het niet! Je wilt zo snel mogelijk uit deze "niet-gerelateerde" specificaties komen en teruggaan naar het afmaken van de andere functie.
Wanneer u alle testgegevens vindt daar waar uw tests u vertellen waar het mislukt, vergroot u uw kansen door dit snel te herstellen zonder een heel ander deel van de app in uw brein te "downloaden"..
U kunt uw code aanzienlijk opschonen en DROGEN door uw eigen hulpmethoden te schrijven. Het is niet nodig om RSpec DSL te gebruiken voor iets dat zo goedkoop is als een Ruby-methode.
Laten we zeggen dat je een paar herhalende armaturen hebt gevonden die een beetje vies worden. In plaats van met een te gaan laat of a onderwerpen, definieer een methode onderaan een beschrijvingsblok - een conventie - en extraheer de overeenkomsten erin. Als het iets breder in een bestand wordt gebruikt, kunt u dit ook onderaan het bestand plaatsen.
Een leuk neveneffect is dat je op die manier niet te maken hebt met semi-globale variabelen. Je zult jezelf ook redden van het maken van een heleboel veranderingen overal als je de gegevens een beetje wilt tweaken. U kunt nu naar één centrale plaats gaan waar de methode is gedefinieerd en van invloed zijn op alle plaatsen waar het tegelijkertijd wordt gebruikt. Niet slecht!
beschrijf Agent, '#current_status' do it 'speculeert over de keuze van de agent van de bestemming als status vacation is' do bond = Agent.new (naam: 'James Bond', status: 'Op vakantie', sectie: '00', licence_to_kill : true) verwachten (bond.current_status) .to eq ('Commander Bond is op vakantie, waarschijnlijk in de Bahama's') en eindigen ermee 'speculeert over de keuze van de kwartiermeester van de bestemming als de status vakantie is' do q = Agent.new (naam: 'Q', status: 'Op vakantie', sectie: '00', licence_to_kill: true) verwacht (q.current_status) .to eq ('Het kwartiermaker is op vakantie, waarschijnlijk op DEF CON') eindeZoals je kunt zien is er een beetje repetitieve setup-code en we willen voorkomen dat we dit steeds opnieuw schrijven. In plaats daarvan willen we alleen de essentiële informatie voor deze test zien en een methode hebben om de rest van het object voor ons te bouwen.
beschrijf Agent, '#current_status' do it 'speculeert over de keuze van de agent van bestemming als status is vacation' do bond = build_agent_on_vacation ('James Bond', 'On vacation') verwacht (bond.current_status) .to eq ('Commander Bond is op vakantie, waarschijnlijk in de Bahama's ') en het' speculeert over de keuze van de kwartiermeester van de bestemming als status vakantie is 'do q = build_agent_on_vacation (' Q ',' On Vacation ') verwacht (q.current_status) .to eq (' De kwartiermaker is met vakantie, waarschijnlijk bij DEF CON ') end def build_agent_on_vacation (naam, status) Agent.new (naam: naam, status: status, sectie:' 00 ', licence_to_kill: true) end endNu zorgt onze geëxtraheerde methode voor de sectie en Licentie om te doden dingen en daardoor niet afleiden van de essentie van de test. Natuurlijk, dit is een dummy voorbeeld, maar je kunt de complexiteit ervan evenveel opschalen als je nodig hebt. De strategie verandert niet. Het is een heel simpele refactoring-techniek - daarom introduceer ik het al vroeg, maar een van de meest effectieve. Het maakt het ook bijna geen pretje om de extractietools die RSpecs biedt te vermijden.
Waar je ook op moet letten, is hoe expressief deze hulpmethoden kunnen zijn zonder een extra prijs te betalen.
Het vermijden van een paar delen van de RSpec DSL en goed gebruik maken van goede ol 'Ruby en object-georiënteerde programmeerprincipes is een goede manier om het schrijven van je tests te benaderen. Je kunt de essentiële dingen vrijelijk gebruiken, beschrijven, context en het, natuurlijk.
Zoek een goede reden om andere delen van RSpec te gebruiken en vermijd ze zo lang als je kunt. Alleen omdat dingen handig en aantrekkelijk lijken, is geen reden genoeg om ze te gebruiken. Het is beter om dingen eenvoudiger te houden.
Eenvoudig is goed; het houdt uw testen gezond en snel.
