Share
Welkom terug! Als je het eerste deel van onze reis tot nu toe hebt gemist, wil je misschien eerst teruggaan en bijpraten.
Tot nu toe hebben we een testgestuurde ontwikkeling toegepast op het bouwen van onze applicatie, naast het gebruik van het populaire RSpec-testraamwerk. Vanaf hier gaan we enkele andere RSpec-functies onderzoeken en kijken naar het gebruik van de Pry-edelsteen om u te helpen uw code te debuggen en te schrijven.
Laten we even stilstaan bij enkele andere RSpec-functies die we niet nodig hebben in deze eenvoudige voorbeeldtoepassing, maar misschien vindt u het handig om aan uw eigen project te werken..
Stel je voor dat je een test schrijft, maar dat je wordt onderbroken of dat je moet vertrekken voor een vergadering en de code nog niet hebt voltooid om de test te laten slagen.
U kunt de test verwijderen en deze later opnieuw schrijven wanneer u terug kunt komen naar uw werk. Of u zou de code gewoon kunnen becommentariëren, maar dat is behoorlijk lelijk en zeker niet goed als u een versiecontrolesysteem gebruikt.
Het beste wat u in deze situatie kunt doen, is om onze test te definiëren als 'in behandeling', dus wanneer de tests worden uitgevoerd, negeert het testraamwerk de test. Om dit te doen, moet u de in afwachting trefwoord:
beschrijf "enige methode" doe het "zou iets moeten doen" in afwachting van het einde
In alle goede testkaders kunt u code uitvoeren voordat en nadat elke test is uitgevoerd. RSpec is niet anders.
Het biedt ons voor en na methoden die ons in staat stellen om een specifieke status in te stellen voor het uitvoeren van onze test, en om die status op te ruimen nadat de test is uitgevoerd (dit is zo dat de toestand niet lekt en de uitkomst van volgende tests beïnvloedt).
beschrijf "enige methode" do before (: each) do # some set-up code end after (: each) do # # some tear-down code end it "should do something" in afwachting van end end
We hebben het al gezien beschrijven blok; maar er is nog een blok dat functioneel equivalent is genaamd context. Je kunt het overal gebruiken waar je zou gebruiken beschrijven.
Het verschil tussen hen is subtiel maar belangrijk: context staat ons toe om een staat te definiëren voor onze test. Maar niet expliciet (we bepalen niet de staat door a te definiëren context blok - het is in plaats daarvan bedoeld voor leesbaarheid, dus de bedoeling van de volgende code is duidelijker).
Hier is een voorbeeld:
beschrijven "Sommige methode" doen context "blok verstrekt" doen het "opbrengsten om te blokkeren" doen in afwachting van eindcontext "geen blok meegeleverd" doe het "roept een terugvalmethode op" doe in afwachting van eind einde
We kunnen de gebruiken stomp methode om een nepversie van een bestaand object te maken en een vooraf vastgestelde waarde te laten retourneren.
Dit is nuttig om te voorkomen dat onze tests API's voor live services raken en om onze tests te sturen door voorspelbare resultaten te geven van bepaalde oproepen.
Stel je voor dat we een klasse hebben genaamd Persoon en dat deze klasse een heeft spreken methode. We willen testen of die methode werkt zoals we verwachten. Om dit te doen zullen we de spreken methode met behulp van de volgende code:
Accentsconagua
beschrijven Persoon doet het "speak ()" do bob = stub () bob.stub (: speak) .and_return ('hallo') Person.any_instance.stub (: initialize) .and_return (bob) instance = Person.new expect ( instance.speak) .naar eq ('hallo') einde In dit voorbeeld zeggen we dat 'elke instantie' van de Persoon klasse moet zijn initialiseren methode gedubd zodat het object wordt geretourneerd bob.
Dat merk je bob is zelf een beginnetje dat zodanig is ingesteld dat elke tijdcode probeert het bestand uit te voeren spreken methode het zal "hallo" terugkeren.
We gaan vervolgens verder met het maken van een nieuw Persoon bijvoorbeeld en geef de oproep van instance.speak in RSpec's verwachten syntaxis.
We vertellen RSpec dat we verwachten dat die aanroep "hallo" in de string resulteert.
In de vorige voorbeelden hebben we de RSpec-functie gebruikt En terugkomen om aan te geven wat ons beginnetje zou moeten terugkomen wanneer het wordt gebeld.
We kunnen een andere retourwaarde aangeven elke keer dat de stub wordt aangeroepen door meerdere argumenten op te geven voor de En terugkomen methode:
obj = stub () obj.stub (: foo) .and_return (1, 2, 3) verwachten (obj.foo ()). naar eq (1) verwachten (obj.foo ()). met eq (2) verwachten (obj.foo ()). naar eq (3)
Mocks lijken op Stubs omdat we valse versies van onze objecten maken, maar in plaats van een vooraf gedefinieerde waarde terug te geven, begeleiden we meer specifiek de routes van onze objecten moet nemen voor de test geldig te zijn.
Om dat te doen gebruiken we de bespotten methode:
beschrijf Obj do it "testing ()" do bob = mock () bob.should_receive (: testing) .with ('content') Obj.any_instance.stub (: initialize) .and_return (bob) instance = Obj.new instance. testen ('enige waarde') einde In het bovenstaande voorbeeld maken we een nieuwe Voorwerp voorbeeld en bel dan de testing methode.
Achter de schermen van die code verwachten we het testing methode die met de waarde moet worden aangeroepen 'inhoud'. Als het niet met die waarde wordt aangeroepen (wat in het bovenstaande voorbeeld niet zo is) dan weten we dat een deel van onze code niet correct heeft gefunctioneerd.
De onderwerpen sleutelwoord kan op verschillende manieren worden gebruikt. Deze zijn allemaal ontworpen om duplicatie van code te verminderen.
Je kunt het impliciet gebruiken (let op onze het blok verwijst niet onderwerpen helemaal niet):
beschrijf Array do omschrijf "met 3 items" do subject [1,2,3] it should_nl be_empty end end
Je kunt het expliciet gebruiken (let op onze het blok verwijst naar onderwerpen direct):
beschrijf MyClass do omschrijven "initialisatie" doen onderwerp MyClass het "maakt een nieuw exemplaar" do instance = subject.new verwachten (instantie) .to be_a (MyClass) end end end
In plaats van voortdurend te verwijzen naar een onderwerp binnen uw code en verschillende waarden door te geven voor instantiatie, bijvoorbeeld:
beschrijf "Foo" do context "A" do it "Bar" do baz = Baz.new ('a') verwacht (baz.type) .to eq ('a') end-end context "B" do it "Bar" do baz = Baz.new ('b') verwacht (baz.type) .to eq ('b') end-end context "C" do it "Bar" do baz = Baz.new ('c') verwacht (baz .type) .naar eq ('c') end-end end U kunt in plaats daarvan gebruiken onderwerpen samen met laat om de duplicatie te verminderen:
beschrijf "Persoon" onderwerp Person.new (naam) # Persoon heeft een get_name methode context "Bob" laat (: naam) 'Bob' its (: get_name) should == 'Bob' einde context "Joe" laat (: naam) 'Joe' zijn (: get_name) should == 'Joe' einde context "Smith" laat (: naam) 'Smith' zijn (: get_name) zou moeten == 'Smith' einde
Er zijn veel meer functies beschikbaar voor RSpec, maar we hebben gekeken naar de belangrijkste functies waarvan je merkt dat je veel gebruikt bij het schrijven van tests met RSpec.
U kunt RSpec configureren om uw tests in een willekeurige volgorde uit te voeren. Hiermee kunt u ervoor zorgen dat geen van uw tests afhankelijk is van of afhankelijk is van de andere tests eromheen.
RSpec.configuratie do | config | config.order = 'willekeurig' einde
U kunt dit instellen via de opdracht met behulp van de --bestellen vlag / option. Bijvoorbeeld: rspec - willekeurige volgorde.
Wanneer u de --willekeurig bestellen optie RSpec geeft het willekeurige nummer weer dat werd gebruikt om het algoritme te seeden. U kunt deze 'seed'-waarde opnieuw gebruiken wanneer u denkt dat u een probleem met afhankelijkheid hebt ontdekt in uw tests. Als je eenmaal hebt opgelost wat volgens jou het probleem is, kun je de seedwaarde doorgeven aan RSpec (bijvoorbeeld als het zaad was 1234 voer dan uit --willekeurig bestellen: 1234) en het zal hetzelfde gerandomiseerde seed gebruiken om te zien of het de oorspronkelijke afhankelijkheids-bug kan repliceren.
U hebt gezien dat we een projectspecifieke set configuratie-objecten hebben toegevoegd binnen onze Rakefile. Maar u kunt configuratie-opties globaal instellen door ze toe te voegen aan een .rspec bestand in uw thuismap.
Bijvoorbeeld binnen .rspec:
--kleur - formaat genest
Nu zijn we klaar om te kijken hoe we onze applicatie en onze testcode kunnen debuggen met behulp van de Pry-edelsteen.
Het is belangrijk om te begrijpen dat, hoewel Pry echt goed is voor het debuggen van uw code, het eigenlijk bedoeld is als een verbeterde Ruby REPL-tool (om te vervangen irb) en niet strikt debugging doeleinden; dus er zijn bijvoorbeeld geen ingebouwde functies zoals: stap in, stap over of stap uit, enz. die je normaal zou vinden in een tool die is ontworpen voor debugging.
Maar als een foutopsporingsinstrument is Pry zeer geconcentreerd en mager.
We komen zo meteen terug naar het debuggen, maar laten we eerst bekijken hoe we Pry in eerste instantie zullen gebruiken.
Om Pry te demonstreren, voeg ik meer code toe aan mijn voorbeeldapplicatie (deze extra code heeft geen enkele invloed op onze test)
class RSpecGreeter attr_accessor: test @@ class_property = "Ik ben een klasse-eigenschap" def greet bind.pry @instance_property = "Ik ben een instantie van een instantie" pubs privs "Hello RSpec!" end def pubs test_var = "Ik ben een testvariabele" test_var end private def privs legt "Ik ben privé" einde
U zult merken dat we een aantal extra methoden, instanties en klasse-eigenschappen hebben toegevoegd. We bellen ook naar twee van de nieuwe methoden die we hebben toegevoegd vanuit onze begroeten methode.
Ten slotte merk je het gebruik van binding.pry.
binding.pry Een breekpunt is een plaats binnen uw code waar de uitvoering stopt.
U kunt meerdere breekpunten instellen in uw code en u maakt ze met behulp van binding.pry.
Wanneer u uw code uitvoert, merkt u dat de terminal stopt en u in de code van uw toepassing plaatst op de exacte plek waar uw binding.pry is geplaatst.
Hieronder ziet u een voorbeeld van hoe het eruit zou kunnen zien ...
8: def greet => 9: binding.pry 10: pubs 11: privs 12: "Hallo RSpec!" 13: einde
Vanaf dit punt heeft Pry toegang tot de lokale scope, zodat je Pry kunt gebruiken zoals je zou doen irb en begin met het invoeren van bijvoorbeeld variabelen om te zien welke waarden ze bevatten.
Je kunt het Uitgang commando om Pry te verlaten en voor je code om door te gaan met uitvoeren.
waar ben ik Bij gebruik van veel binding.pry breekpunten kan het moeilijk zijn om te begrijpen waar in de applicatie je bent.
Om een betere context te krijgen van waar u zich op enig moment bevindt, kunt u de waar ben ik commando.
Als het alleen wordt uitgevoerd, ziet u iets soortgelijks als toen u het gebruikte binding.pry (je ziet de regel waarop het breekpunt was ingesteld en een paar regels erboven en daaronder). Het verschil is als je een extra numeriek argument doorgeeft whereami 5 je ziet vijf extra regels boven waar de binding.pry was geplaatst. U kunt bijvoorbeeld vragen om 100 regels rond het huidige breekpunt te zien.
Met deze opdracht kunt u zich oriënteren binnen het huidige bestand.
wtf De wtf command staat voor "what the f ***" en biedt een volledige stacktracering voor de meest recente uitzondering die is gegenereerd. Het kan u helpen de stappen te begrijpen die voorafgingen aan de opgetreden fout.
ls De ls commando laat zien welke methoden en eigenschappen beschikbaar zijn voor Pry.
Als het wordt uitgevoerd, toont het iets als ...
RSpecGreeter # methoden: greet pubs test test = klassevariabelen: @@ class_property locals: _ __ _dir_ _ex_ _file_ _in_ _out_ _pry_
In het bovenstaande voorbeeld kunnen we zien dat we vier openbare methoden hebben (onthoud dat we onze code hebben bijgewerkt met een aantal aanvullende methoden en dan test en test = werden gemaakt bij het gebruik van Ruby's attr_accessor korte hand).
Het toont ook andere klasse en lokale variabelen die Pry kan gebruiken.
Een ander nuttig ding dat u kunt doen, is de resultaten grep (zoeken) voor alleen datgene waarin u bent geïnteresseerd. U moet kennis hebben van reguliere expressies, maar het kan een handige techniek zijn. Hier is een voorbeeld…
ls -p-G ^ p => RSpecGreeter # methoden: privs
In het bovenstaande voorbeeld gebruiken we de -p en -G opties / vlaggen die Pry vertellen dat we alleen publieke en private methoden willen zien en we gebruiken de regex ^ p (wat overeenkomt met alles wat begint met p) als ons zoekpatroon om de resultaten te filteren.
hardlopen ls --help toont ook alle beschikbare opties.
CD U kunt het huidige bereik wijzigen met behulp van de CD commando.
In ons voorbeeld als we rennen cd ... / pubs het brengt ons naar het resultaat van die methodeaanroep.
Als we nu vluchten waar ben ik je zult zien dat het zal verschijnen Inside "Ik ben een testvariabele".
Als we vluchten zelf dan zul je zien dat we het krijgen "Ik ben een testvariabele" teruggekeerd.
Als we vluchten self.class we zullen zien Draad teruggekeerd.
U kunt met behulp van de scoleketen omhoog gaan CD… of u kunt teruggaan naar het hoogste niveau van het bereik met cd /.
Opmerking: we kunnen nog een toevoegen binding.pry binnen in de pubs methode en dan zou onze scope binnen die methode vallen in plaats van het resultaat van de methode.
nesting Overweeg het vorige voorbeeld van hardlopen cd-pubs. Als we het nesting opdracht krijgen we een blik op het hoogste niveau van het aantal contexten / niveaus dat Pry momenteel heeft:
Broedstatus: - 0. # (Pry top level) 1. "Ik ben een testvariabele"
Vanaf daar kunnen we rennen Uitgang om terug te gaan naar de eerdere context (bijvoorbeeld binnen de begroeten methode)
hardlopen Uitgang opnieuw betekent dat we de laatste context sluiten die Pry heeft en dus eindigt Pry en onze code blijft lopen.
find-methode Als u niet zeker weet waar u een bepaalde methode kunt vinden, kunt u de find-methode opdracht om alle bestanden in uw codebasis weer te geven met een methode die overeenkomt met wat u zoekt:
find-method priv => Kernel Kernel # private_methods Module Module # private_instance_methods Module # private_constant Module # private_method_defined? Module # private_class_method Module # private RSpecGreeter RSpecGreeter # privs
U kunt ook de -c optie / vlag om in plaats daarvan de inhoud van bestanden te doorzoeken:
find-methode -c greet => RSpecGreeter RSpecGreeter: def greet RSpecGreeter # privs: greet
volgende, stap, doorgaan met Hoewel bovenstaande technieken nuttig zijn, is het niet echt 'debugging' in dezelfde zin als wat u waarschijnlijk gewend bent.
Voor de meeste ontwikkelaars biedt hun editor of browser een ingebouwde foutopsporingstool waarmee ze hun code regel voor regel kunnen doorlopen en de route kunnen volgen die de code nodig heeft tot de voltooiing.
Omdat Pry is ontwikkeld om als een REPL te gebruiken, wil dit niet zeggen dat het niet nuttig is voor foutopsporing.
Een naïeve oplossing zou zijn om meerdere in te stellen binding.pry uitspraken door middel van een methode en gebruik ctrl-d om door elke breekpuntset te bewegen. Maar dat 'nog steeds niet helemaal goed genoeg.
Voor stapsgewijze debugging kunt u de gem pry-nav laden ...
bron "https://rubygems.org" gem 'rspec' group: ontwikkeling doe gem 'guard' gem 'guard-rspec' gem 'pry' # Voeg debugging-stappen toe aan Pry # ga verder, stap, volgende 'pry-remote' juweeltje gem 'pry-nav' einde
Dit juweeltje breidt Pry uit, zodat het de volgende opdrachten begrijpt:
volgende (ga naar de volgende regel)Stap (ga naar de volgende regel en als het een methode is, ga dan naar die methode)Doorgaan met (Negeer eventuele verdere breekpunten in dit bestand)Als een toegevoegde bonus laten we onze tests integreren met de online CI (continuous integration) -service Travis-CI.
Het principe van CI is om vroegtijdig te committeren / duwen en vaak om conflicten tussen uw code en de mastertak te vermijden. Wanneer je dat doet (in dit geval doen we GitHub), dan zou dat een 'build' moeten zijn op je CI-server die de relevante tests uitvoert om te zorgen dat alles werkt zoals het zou moeten zijn.
Nu TDD uw primaire ontwikkelmethodologie is, hebt u minder kans om bugs op te lopen elke keer dat u pusht, omdat uw tests een integraal onderdeel zijn van uw ontwikkelworkflow en dus voordat u pusht, bent u zich al bewust van bugs of regressies. Maar dit hoeft u niet noodzakelijk te beschermen tegen fouten die optreden bij integratietests (waarbij alle code over meerdere systemen samen wordt uitgevoerd om te zorgen dat het systeem 'als geheel' correct functioneert).
Hoe dan ook, code mag nooit rechtstreeks naar uw live-productieserver worden doorgestuurd; het moet altijd eerst naar een CI-server worden gepusht om potentiële bugs op te sporen die voortkomen uit verschillen tussen uw ontwikkelomgeving en de productieomgeving.
Veel bedrijven hebben nog steeds meer omgevingen om hun code door te geven voordat deze de live productieserver bereikt.
Op BBC News hebben we bijvoorbeeld:
Hoewel elke omgeving identiek moet zijn in de set-up, is het doel om verschillende soorten testen te implementeren om ervoor te zorgen dat zoveel bugs worden gepakt en opgelost voordat de code 'live' wordt bereikt.
Travis CI is een gehoste continue integratieservice voor de open-sourcecommunity. Het is geïntegreerd met GitHub en biedt eersteklas ondersteuning voor meerdere talen
Wat dit betekent is dat Travis-CI gratis CI-services biedt voor open-sourceprojecten en ook een betaald model heeft voor bedrijven en organisaties die hun CI-integratie privé willen houden.
We zullen het gratis open-source model gebruiken in onze voorbeeld GitHub-repository.
Het proces is dit:
.travis.yml bestand in de hoofdmap van uw project en verbind het met uw GitHub-repositoryDe laatste stap is de belangrijkste (het maken van een .travis.yml bestand), omdat dit de configuratie-instellingen voor Travis-CI bepaalt, zodat deze weet hoe om te gaan met het uitvoeren van de tests voor uw project.
Laten we eens kijken naar de .travis.yml bestand dat we gebruiken voor onze voorbeeld GitHub-repository:
taal: ruby cache: bundler rvm: - 2.0.0 - 1.9.3 script: 'bundel exec rake spec' bundler_args: --zonder ontwikkelingstakken: alleen: - hoofdmeldingen: e-mail: - [email protected]
Laten we dit stuk voor stuk opsplitsen ...
Eerst specificeren we welke taal we gebruiken in ons project. In dit geval gebruiken we Ruby: taal: robijn.
Omdat het uitvoeren van Bundler een beetje traag kan zijn en we weten dat onze afhankelijkheden niet zullen veranderen, kunnen we er vaak voor kiezen om de afhankelijkheden in de cache op te slaan. cache: bundler.
Travis-CI gebruikt RVM (Ruby Version Manager) voor het installeren van Rubies op hun servers. Dus we moeten specificeren met welke Ruby-versies we onze tests willen uitvoeren. In dit geval hebben we gekozen 2.0 en 1.9.3 Dit zijn twee populaire Ruby-versies (technisch gezien gebruikt onze applicatie Ruby 2, maar het is goed om te weten dat onze code ook in andere versies van Ruby past):
rvm: - 2.0.0 - 1.9.3
Voor het uitvoeren van onze tests weten we dat we het commando kunnen gebruiken hark of rake spec. Travis-CI voert standaard de opdracht uit hark maar vanwege hoe edelstenen zijn geïnstalleerd op Travis-CI met behulp van Bundler, moeten we de standaardopdracht wijzigen: script: 'bundel exec rake spec'. Als we dit niet deden, zou Travis-CI een probleem hebben met het lokaliseren van de rspec / kern / rake_task bestand dat is opgegeven in onze Rakefile.
Opmerking: als je problemen hebt met Travis-CI, kun je lid worden van het #travis-kanaal op IRC-freenode om hulp te krijgen bij het beantwoorden van al je vragen. Dat is waar ik de oplossing voor mijn probleem ontdekte waarbij Travis-CI mijn tests niet kon uitvoeren met de standaardwaarde hark opdracht en de suggestie om de standaardwaarde te overschrijven met bundel exec rake heeft dit probleem opgelost.
Omdat we alleen geïnteresseerd zijn in het uitvoeren van onze tests, kunnen we aanvullende argumenten doorgeven aan Travis-CI om edelstenen te filteren die we niet willen laten installeren. Dus voor ons willen we de installatie van edelstenen die gegroepeerd zijn als ontwikkeling uitsluiten: bundler_args: --zonder ontwikkeling (dit betekent dat we edelstenen uitsluiten die alleen echt worden gebruikt voor ontwikkeling en debugging zoals Pry en Guard).
Het is belangrijk op te merken dat ik oorspronkelijk Pry in onze laden spec_helper.rb het dossier. Dit veroorzaakte een probleem bij het uitvoeren van de code op Travis-CI, nu ik 'ontwikkeling' edelstenen uitsluitte. Dus ik moest de code zo aanpassen:
vereisen 'koersen' als ENV ['APP_ENV'] == 'debug'
Je kunt zien dat de Pry-edelsteen dat nu is vereisen'ed als een omgevingsvariabele van APP_ENV is ingesteld om te debuggen. Op deze manier kunnen we voorkomen dat Travis-CI fouten maakt. Dit betekent wel dat wanneer u uw code lokaal uitvoert, u de omgevingsvariabele moet instellen als u uw code wilt debuggen met Pry. Het volgende laat zien hoe dit op één regel kan worden gedaan:
APP_ENV = debug && ruby lib / example.rb
Er waren nog twee andere wijzigingen die ik heb aangebracht en die was voor onze Gemfile. Een daarvan was om duidelijk te maken welke edelstenen nodig waren voor testen en die nodig waren voor ontwikkeling, en de andere was expliciet vereist door Travis-CI:
bron "https://rubygems.org" groep: test do gem 'rake' gem 'rspec' eindgroep: ontwikkeling doe edelsteen 'bewaker' edelsteen 'bewaker-rspec' gem 'koerier' # Voeg debugging-stappen toe aan Pry # ga verder, stap, volgende edelsteen 'pry-remote' edelsteen 'pry-nav' einde
Kijkend naar het bovenstaande bijgewerkt Gemfile we kunnen zien dat we de RSpec-edelsteen in een nieuw hebben veranderd test groep, dus nu zou het duidelijker moeten zijn welk doel elk juweel heeft. We hebben ook een nieuw toegevoegd gem 'rake'. In de documentatie van Travis-CI staat dat dit expliciet moest worden vermeld.
Het volgende gedeelte is optioneel en u kunt witte lijst (of zwarte lijst) van bepaalde branches in uw repository gebruiken. Travis-CI voert dus standaard tests uit op al uw filialen, tenzij u het anders vertelt. In dit voorbeeld vertellen we het dat we alleen willen dat het tegen ons inloopt meester tak:
takken: alleen: - meester
We zouden het kunnen zeggen om elke tak 'behalve' een bepaalde tak uit te voeren, zoals zo:
takken: behalve: - some_branch_I_dont_want_run
De laatste sectie vertelt Travis-CI waar berichten moeten worden verzonden wanneer een build mislukt of slaagt:
meldingen: e-mail: - [email protected]
U kunt desgewenst meerdere e-mailadressen opgeven:
meldingen: e-mail: - [email protected] - [email protected] - [email protected]
U kunt specifieker zijn en specificeren wat u wilt doen, hetzij bij een fout of een succes (er zullen bijvoorbeeld meer mensen zijn die alleen geïnteresseerd zijn als de tests falen in plaats van een e-mail te ontvangen telkens wanneer ze passeren):
notificaties: e-mail: ontvangers: - [email protected] on_failure: change on_success: never
Het bovenstaande voorbeeld laat zien dat de ontvanger nooit een e-mail zal ontvangen als de tests slagen, maar een melding krijgt als de status van de fout verandert (de standaardwaarde voor beide is altijd wat betekent dat je altijd op de hoogte wordt gesteld, ongeacht het statusresultaat).
Opmerking: wanneer u expliciet een on_failure of on_success je moet de e-mailadressen binnenin verplaatsen ontvangers sleutel.
Dit is het einde van onze tweedelige blik op RSpec, TDD en Pry.
In deel één zijn we erin geslaagd om onze applicatie te schrijven met behulp van het TDD-proces en het RSpec-testraamwerk. In deze tweede helft hebben we ook Pry gebruikt om te laten zien hoe we een lopende Ruby-applicatie gemakkelijker kunnen debuggen. Eindelijk konden we onze testopstelling laten uitvoeren als onderdeel van een continue integratieserver met behulp van de populaire Travis-CI-service.
Hopelijk heeft dit je genoeg smaak gegeven, dus je wilt elk van deze technieken verder onderzoeken.
