RSpec testování pro začátečníky, část 1

() translation by (you can also view the original English article)

Jste nový na kolejích? Nové kódování? Kuriózní RSpec a jak můžete začít testování? Pokud ano, Tento článek by měl být dobrým výchozím bodem pro vás dostat do vývoje řízeného testováním. To vám vysvětlí proč a jak, a bude vám přežití kit jít na své první zkušební spree.

Témata

O co jde?
RSpec?
Začínáme
Spouštění testů
Základní syntaxe
Čtyři fáze testů
Těžké něco o testování

O co jde?

Co je dobré pro RSpec? RSpec je velmi užitečné na úrovni Test jednotky testování jemnější detaily a obchodní logiky aplikace. To znamená testování vestavby jako modely a řadiče vaší aplikace. Testy, které pokrývají vaše názory nebo funkce testy, které simulují úplnější uživatele toky, jako nákup položky, nebude soustředit, že RSpec je pro. RSpec nedělá využívání web řidiče – stejně jako kabie, například –, které simuluje uživatelské interakce s skutečné místo nebo její vyobrazení.

Vývoj řízený testováním (TDD), o co jde? No, to není tak snadné odpovědět bez krmení nějaké klišé. Doufám, že to nezní úhybné manévry. By mohl poskytnout rychlou odpověď, ale chci se vyhnout posílali že domů hladový po mají jen malé občerstvení. Výsledkem tohoto malého seriálu o RSpec a testování by nejen dát vám veškeré info na tuto otázku odpovědět sami, ale také poskytnout vám s prostředky a porozumění, aby začít s testováním zároveň cítil trochu jistotu již o testování věc.

Zdá se, že Začátečníci mají těžší dostat do RSpec a TDD workflow než začíná být nebezpečné s Ruby nebo zábradlí. Proč to je? Mohu jen hádat, v tomto bodě, ale na straně jedné literatuře se zdá většinou zaměřuje na lidi, kteří již mají nějaké znalosti programování pod jejich vedením, a na straně druhé učí všechny věci, které se účastní mít jasnou představu je trochu skličující. Křivka učení může být poměrně strmý, předpokládám. Pro efektivní testování, jsou zapojeny spoustu pohyblivých částí. Je to hodně požádat o nováčky, kteří právě začali porozumět rámec jako kolejnice podívat se na proces vytváření aplikace z opačné perspektivy a naučit zcela nové API pro psaní kódu pro váš kód.

Přemýšlel jsem o jak přistupovat k této "dilema" pro příští generaci programátorů, kteří jen hledají hladšího startu do toho. Je to, co jsem vymyslel. Já se rozdělit základní syntaxe pro vás bez za předpokladu, že je mnohem více než základní znalosti o Ruby a trochu kolejnic. Pokrývá všech možných úhlů a matoucí, vás k smrti, půjdeme přes základní přežití kit a snaží se malovat větší obrázek. Budeme diskutovat o "Jak?" spíše podrobn─ v aby nedošlo ke ztrátě nové programátory podél cesty. Druhá část rovnice bude vysvětlení, "Proč?"

Když budu mít štěstí, dostanete pryč s dobrým základem pro pokročilejší knihy zároveň cítil jistotu o větší obrázek. Ok teď, půjdeme se projít na procházku!

Výhody a tak

Vraťme se k účelu testování. Je testování užitečné pro psaní lepší kvalitu aplikace? No, to může být značně diskutuje, ale v okamžiku, kdy já bych odpovědět na tuto otázku ano – jsem v táboře bokovky TDD, myslím. Podívejme, proč testy poskytují své aplikace s pár výhod, které jsou těžké ignorovat:

Budou kontrolovat, pokud vaše pracovní funkce jako určena. Neustále na ověření, že jste psaní kódu, že práce je zásadní pro zdraví vaší aplikace a váš tým zdravý rozum.

Testují věci, které nechcete otestovat ručně, zdlouhavé kontroly, které můžete udělat ručně – zejména když budete muset zkontrolovat celou dobu. Chcete být tak jistý, jak je to možné, že vaše nové funkce nebo nové třídy nebo co nezpůsobuje žádné vedlejší účinky v možná zcela nepředvídatelných oblastech aplikace. Automatizace takovéhle věci nejen vám ušetří spoustu času, ale také provést testování scénářů, konzistentní a opakovatelné. Sama to dělá, je mnohem spolehlivější než chyba prone testování ručně.

Chceme, aby se ujistil, že že aplikace chová určitým způsobem, očekávaným způsobem. Testy můžete zajistit na docela vysoké míry, že způsob, jakým uživatelé pracují s aplikací je funkční a vyhnout se chyba scénáře, které jste schopni předvídat. Testy zkontrolujte, zda aplikace funguje, jak jste ho navrhli – a že i nadále fungovat po zavedení změny. To je obzvláště důležité, když testovací sady vás informuje o selhání scénáře o implementace aplikace, které by mohly být staré a proto není přesně v zadní části vašeho mozku už a ne za to, zatímco vy zavedeny některé nové funkce. Stručně řečeno pomáhá udržovat zdravé aplikace a zabraňuje zavedení spoustu chyb.

Automatizace testů, abyste skutečně test častěji. Představte si, že máte otestovat něco pro 40 čas z nějakého důvodu. Pokud je to jen trochu časově náročné, jak snadné to bude nudit a úplně vynechat proces? Tyto druh věci jsou prvním krokem na kluzkém svahu, kde můžete políbit slušné procento kódu disponibility sbohem.

Testy fungují jako dokumentace. Cože? Specifikace, kterou píšete přidělovat ostatním uživatelům na vaše týmy rychlé vstupní bod se učit nový základ kódu a pochopit, co to má dělat. Psaní kódu v RSpec, například, je velmi výrazná a tvoří vysoce čitelný bloky kódu, které vyprávějí příběh Pokud se provádí správně. Protože to může být napsán velmi popisně zároveň je velmi stručné konkrétní jazyk domény (DSL), RSpec zasáhne dvě mouchy jednou ranou: ne zbytečných řečí v jeho API a poskytuje tak všemi prostředky psát scénáře testování velmi pochopitelné. To je to, co jsem měla ráda o tom a myslím, že důvod, proč jsem nikdy opravdu teplé s okurkou, která řešila stejný problém v příliš klienta příjemným způsobem.

Mohou minimalizují množství kódu, který napíšete. Místo slepení kolem jako blázen, vyzkoušet věci více freestyle, praxe zkoušku váš kód vám umožňuje psát pouze kód, který je nutné projít testy. Žádný přebytek kód. Věc, kterou často uslyšíte ve své budoucí kariéře je, že nejlepší kód je kód, který není nutné psát, nebo tak něco. Proč? Dobře, nejčastěji, elegantnější řešení zahrnují menší množství kódu a také kód, který nechcete psát – což může být zbytečné – nezpůsobí všechny budoucí chyby a nemusí být zachována. Tak psaní testů nejprve, než napíšete implementace, dává jasné zaměření na problém, který potřebujete řešit dále. Zápis pouze kód, který je nezbytné a ne náhodou víc, je možná nedoceněný vedlejší účinek, který vám může poskytnout TDD.

Mají pozitivní vliv na váš návrh. Pro mě pochopení této části zapnuté žárovky a mě opravdu ocení testovací věc. Když píšete vaše implementace kolem scénáře testování velmi soustředěný, váš kód bude s největší pravděpodobností zase vystoupit a být mnohem více zpřehlednění a modulární. Vzhledem k tomu, jsme všichni přátelé suché – "Neopakujte sami!" — a jako malý spojku mezi komponentami ve vaší aplikaci, jak je to možné, je to jednoduchý, ale efektivní disciplína k dosažení systémy, které jsou navrženy dobře od země nahoru. Tento aspekt je nejvýznamnějším přínosem, myslím. Ano, ty ostatní jsou také docela super, ale když testy má také za následek aplikace, jejichž kvalita je lepší díky rafinované konstrukci, řekl bych, že Jackpot!

To se scvrkává na peníze stejně. Když máte stabilní aplikace, která se snadno udržuje a snadno změnit, ušetříte dost peněz v dlouhodobém horizontu. Zbytečné složitost může strašit projekty snadno a motivace nebude na maxima, když váš tým musí bojovat váš kód, protože je křehký a špatně navržené. Dobrá aplikace design naprosto podporují vaše obchodní cíle – a naopak. Chcete zavést některé nové funkce, které jsou zásadní pro vaše podnikání, ale neustále bojují vaši architekturu, protože byla postavena na písku? Samozřejmě že ne a všichni jsme viděli mnoho příkladů podniků, které rychle zmizel pro tento přesný důvod. Dobré testování zvyky mohou být efektivní linii obrany pro takové situace.

Dalším cílem, který je důležité, je ve vztahu ke kvalitě samotného kódu. Software, píšete, by měl být snadno srozumitelné pro ostatní vývojáře – co nejvíce, alespoň. Testy mohou skutečně pomoci zprostředkovat funkčnost a záměr aplikace – a nejen k ostatním členům týmu, ale do své budoucí já. Je-li určitou část kódu Nesahej na nějakou dobu, opravdu bude vhodné znovu připomínat jak a proč jste napsal kus software s dokumentací, která poskytuje nástroj jako RSpec – a RSpec dělá to opravdu dobře , výjimečně ve skutečnosti.

Vzhledem k tomu, váš kód bude vždy měnit, refaktoring kódu vůli a by měla být vždy součástí vývoje softwaru. A protože změna je tak peče do tohoto procesu, je třeba Ujistěte se, že tyto změny negenerují neočekávané vedlejší účinky překvapivá místa. Test suite vám dává pěkně vyladěné bezpečnostní čistou cítit pohodlně a zdarma na Refaktorovat s chutí. Tento aspekt, vedle výhody konstrukce, TDD může poskytnout vám nabízí, je můj oblíbený prospěch test suite vám může pomoci. Úprava a rozšíření kódu je tak nezbytnou součástí inovaci na již vydané "produktu" že potřebujete nástroj, který vám dává tolik svobody, jak je to možné s tímto procesem. Nejsem si jistý, jestli lidé, kteří jsou kritické psaní rozsáhlé testovací sady jsou mnohem obavy o tomto aspektu.

Budete mít dobrou šanci na budování nové věci rychleji v pozdějších fázích, protože zpětná vazba od test suite vám poskytne zpětnou vazbu o selhání, chyby a omezení – mnohem rychleji, než člověk může vyzkoušet, samozřejmě. Plus bude vám důvěru pracovat s bezpečnostní síť, se stává ještě cennější, déle jste jít.

V aplikacích zejména v případě, že mají vzrostl výrazně, budete chtít mít možnost důvěřovat softwaru. 100 % pokrytí kódu zní mnohem sladší, když máte web, který je pár let stará a dojatý stovky vývojářů. Být schopen důvěřovat nový kód představit a budova na vrcholu, že je jedním z blisses vývoje softwaru, že peníze nemůže koupit později.

Začínáme

Terminál

1	rails new your_app -T

-T umožňuje přeskočit Test jednotky, testování rámce, který je dodáván s Rails.

Gemfile

1	group :development, :test do
2	gem 'rspec-rails'
3	end

Terminál

bundle

Poté je třeba spustit generátor, který je dodáván s RSpec:

Terminál

1	rails generate rspec:install

Výstup

1	create .rspec
2	create spec
3	create spec/spec_helper.rb
4	create spec/rails_helper.rb

Co to dělá, je nastavit základní strukturu pro RSpec testy v Rails. Jak z výše uvedeného výstupu můžete vidět, tento generátor inicializován spec adresář s pár souborů, které budete potřebovat později. .Rspec soubor je konfigurační soubor, který nebudeme muset pracovat pro tuto chvíli. Jen jsem chtěl, abyste věděli, co máte před sebou. Ostatní soubory jsou zřejmé, ale chtěl jsem zmínit jejich rozdíly.

spec_helper.RB je pro specifikace, které nejsou závislé na kolejích.
rails_helper.RB, na straně druhé je pro specifikace, které na ní závisí.

Co není jasné je, že jeden z těchto souborů musí být vyžadována na vrcholu své spec soubory (testovací) testy. Dáme si rychlý pohled! Při generování modelu prostřednictvím:

Terminál

1	rails generate model dummy_model name:string

Výstup

invoke  active_record
create    db/migrate/20160521004127_create_dummy_models.rb
create    app/models/dummy_model.rb
invoke    rspec
create    spec/models/dummy_model_spec.rb

Nejenže bude kolejnice vytvořili přidružené _spec.rb, které soubory pro vás, vaše specifikace bude mít také automaticky vyžadují "rails_helper" ve výchozím nastavení v horní části spec soubory. To znamená, že jste připraveni jít, hned.

Spec/Models/dummy_model_spec.RB

1	require 'rails_helper'
2
3	...

Tak s tímto nastavením můžete otestovat vaší Rails aplikace, vaše modely například a RSpec nebude se zmást o modelu třídy používané v kolejnicích. To je nezbytné, aby vždy, když potřebujete věci jako ActiveRecord, ApplicationController a tak dále. Tak to je váš normální scénář a proto by měla být vaše první logickou volbou jako začátečník.

Vyžadující spec_helper.rb, na druhé straně vyvolá chybu, pokud budete psát testy, které obsahují obchodní logiku od Rails aplikace. V tomto scénáři RSpec nevím, co mluvíte o kdy budete chtít vyzkoušet některé kolejnice modelu, například.

Tak dlouhý příběh super krátký, spec_helper nenačte kolejnice – to je ono! Samozřejmě můžete jít volně žijících s konfigurací, ale to není nic že chci abyste o právě teď zajímat. Soustřeďme se na základy, jak spouštět testy a syntaxi. To by mělo pro začátek stačit. Pojďme dál!

Spouštění testů

Jste připraveni ke spuštění testů. RSpec vyžaduje testovací soubory konkrétní příponu jako _spec porozumět soubory, které chcete spustit. Pokud používáte generátor, to se netýká, ale pokud chcete psát testovací soubory na vlastní pěst, je to, jak je třeba ukončit. Takže budete muset dát soubor jako your_first_test_spec.rb v adresáři spec.

Pomocí generátoru pro vytvoření fiktivní modelu už nám poskytl spec/models/dummy_model_spec.rb. Není to zlé! Jedna věc, kterou udělat předtím, než jsou připraveny testy:

Terminál

1	rake db:migrate
2	rake db:test:prepare

Tyto příkazy jsou spouštěny migrace pro maketu jsme vygenerovali výše a nastavit testovací databáze s tímto modelem. Nyní můžeme skutečně spustit test:

Terminál

rake

Hrábě příkaz spustí všechny testy, kompletní test suite. Obvykle měli použít tento příkaz, když jste dokončili některé funkce a chtějí vykonávat celý test suite.

Výstup

*
Pending: (Failures listed here are expected and do not affect your suite's status)

1) DummyModel add some examples to (or delete) /Users/vis_kid/projects/rspec-test-app/rspec-dummy/spec/models/dummy_model_spec.rb
   # Not yet implemented
   # ./spec/models/dummy_model_spec.rb:4

Finished in 0.00083 seconds (files took 1.94 seconds to load)

1 example, 0 failures, 1 pending

Blahopřejeme! Jste právě spustili první test RSpec. Není to špatné, bylo to? Samozřejmě, to byl orientační zkouška pro tuto chvíli – s fiktivní testovací kód generovaný kolejnice. Cílenější verzi spuštění testů – máte ve skutečnosti mnohem více možností než jen to, že – je spustit soubor, například. Nějak tak:

Terminál

1	bundle exec rspec spec/models/dummy_model_spec.rb

To lze spustit pouze jeden testovací soubor namísto celý test suite. S větší aplikace, které závisí na vysoké množství testovacích souborů to se stane v reálném čase spořiče. Ale co se týká úspor času a testování specifičnosti, to je jen poškrábání povrchu, abych byl upřímný. Myslím, že víc jak ohoblovat značné množství času při testování v třetím článku v tomto seriálu se budeme zabývat. Podívejme se, jak daleko jsme se!

Na druhou stranu vykonávat celý test suite je pouhým spuštěním rspec – s nebo bez svazku exec, v závislosti na nastavení.

Terminál

1	bundle exec rspec

Ještě jedna věc, kterou bych měl zmínit, ještě než se vrhneme, můžete také spustit pouze určitou podmnožinu testů. Řekněme, že chcete spustit všechny testy pro váš kód modelu:

Terminál

1	bundle exec rspec spec/models

To snadné!

Základní syntaxe

Doporučuji, že začneme s holé základy a podívat se do několika další možnosti, které RSpec poskytuje v následujících dvou článcích. Podívejme se na základní strukturu testu a ponořit se do pokročilejší vod, když máme tenhle z cesty.

popsat

To bude váš chleba s máslem, protože jej organizuje vaše specifikace. Můžete odkazovat řetězce nebo samotné třídy:

Některé Spec

describe User do

end

describe 'Some string' do

end

popsat části jsou základními stavebními kameny uspořádat testy do logických, soudržné skupiny k testování. V podstatě prostor pro různé části aplikace, které chcete testovat.

Některé Spec

describe User do
  ...
end

describe Guest do
  ...
end

describe Attacker do
  ...
end

Dobrým tipem je utáhnout ještě více váš obor. Vzhledem k tomu, některé třídy se docela výrazně zvýší, není vhodné mít všechny metody, které chcete testovat pro jednu třídu v jednom popisujících bloku. Můžete vytvořit více těchto bloků, samozřejmě a soustředit kolem instance nebo metody třídy namísto. Aby váš záměr jasnější, vše co potřebujete je poskytnout název třídy navíc řetězec, který odkazuje na metodu, kterou chcete testovat.

Některé Spec

describe Agent, '#favorite_gadget' do
  ...
end

describe Agent, '#favorite_gun' do
  ...
end

describe Agent, '.gambler' do
  ...
end

Tímto způsobem získáte to nejlepší z obou světů. Související testy v jejich zapouzdření, při zachování věci zaměřené a na slušné velikosti. Pro uživatele velmi nové pro Ruby půdy měl bych zmínit, že # jednoduše odkazuje na metodu instance, zatímco dot. je vyhrazen pro metody třídy. Protože jsou uvnitř řetězce, zde nemají žádné technické důsledky, ale signalizují váš záměr ostatním vývojářům a své budoucí já. Nezapomeň se čárka za názvem třídy – bez něj to nepůjde! Ve chvíli, kdy dostaneme očekávat, budu ukázat, proč je tento přístup super pohodlné.

to

V rámci skupin popisujících používáme jiný rozsah bloků. Ty jsou vyrobeny pro skutečné příklady zkoušeného. Pokud chcete testovat metodu instance #favorite_gadget na třídě agenta, to by vypadat takto:

Některé Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    ...
  end

end

Řetězec, který zadáte do it blok funguje jako hlavní dokumentaci k testu. V ní určit přesně jaký druh chování, které chcete nebo očekávat od předmětné metody. Mé doporučení je jít přes palubu a být příliš podrobného o tom, ale nechcete být příliš kryptických a ostatní pletou s přehnaně inteligentní popisy.

Přemýšlejte o co nejmenší a nejjednodušší provedení této části skládačky a by měl provést. Lépe napsat tuto část, tím lepší celkovou dokumentaci k aplikaci. Nespěchej tuto část, protože je to jen řetězec, který nepoškodí – alespoň ne na povrchu.

Expect()

Teď jsme se více k jádru věci. Tato metoda umožňuje ověřit nebo pozměňování část systému, který chcete testovat. Vraťme se k našemu předchozímu příkladu a vidět v akci (omezené):

Některé Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

Expect() je "nové" syntaxe výrazu RSpec. Dříve jsme používali místo. Jiný příběh, ale já jsem chtěl zmínit, že v případě, že narazíte na to. Expect() očekává, že poskytne objektu a vykonávat jakoukoli metodu testovaný na něm. Nakonec zapište hlášená výsledek na pravé straně.

Máte možnost jít cestou kladné nebo záporné .na eq nebo .not_to eq pro příklad (eq je zkratka pro rovné samozřejmě). Jste vždy otočit logiku – nejlepší co vyhovuje vašim potřebám. Pojďme tento nesmyslný test a zaměřit se na výstup, který jsme dostali v důsledku testovacím uspořádáním:

Terminál

1	rspec spec/models/agent_spec.rb

Výstup

1	Failures:
2
3	1) Agent#favorite_gadget returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Čte se krásně, ne? ** "Agent #favorite_gadget vrátí jednu položku a oblíbený gadget agent" ** zjistíte vše, co potřebujete vědět:

Třída zapojených
metodu testovaný
očekávaný výsledek

Pokud jsme už přestali řetězec, který popisuje metodu v bloku popsat, pak výstup by byla mnohem méně jasný a čitelný:

Některé Spec

describe Agent do

  it 'returns one item, the favorite gadget of the agent ' do
    expect(agent.favorite_gadget).to eq 'Walther PPK' 
  end

end

Výstup

1	Failures:
2
3	1) Agent returns one item, the favorite gadget of the agent
4	Failure/Error: expect(agent.favorite_gadget).to eq 'Walther PPK'

Jistě, existují jiné způsoby, jak obejít a vypořádat se s tímto – předejte tyto informace prostřednictvím vašeho it blokovat, například – ale jiný přístup je prostě jednoduchý a funguje. Co dělá váš krevní oběh, samozřejmě!

Čtyři fáze testu

Doporučené postupy v testování doporučují, že skládáme naše testy ve čtyřech odlišných fázích:

nastavení testu
zkušební cvičení
test ověření
testovat rušením

Tyto čtyři fáze jsou většinou pro čitelnost a dát vaše testy běžných staveb. Je to takzvaný testovací vzorek, v podstatě, jednání, které by Společenství široce dohodly na vhodné a doporučené. Toto téma vzory je hluboké králičí nory, tak vím, že já nechám několik tak, aby se zmást začátečníky mezi vás k smrti.

Instalace

Během instalace si připravit scénář, podle něhož má být spuštěn test. Ve většině případů to bude obsahovat údaje potřebné k být připraveni na nějaké cvičení. Malý tip: nemají komplikovala věci a nastavit pouze minimální množství nutné udělat test práce.

1	agent = Agent.create(name: 'James Bond')
2	mission = Mission.create(name: 'Moonraker', status: 'Briefed')

Cvičení

Tato část skutečně provozuje to, co chcete testovat v tomto spec. By mohlo být stejně jednoduché jako:

1	status = mission.agent_status

Ověřit

Teď si ověřit, pokud je vaše tvrzení o testu splnění nebo ne. Tak otestovat systém proti své vlastní očekávání.

1	expect(status).not_to eq 'MIA')

Rušením

Rámec se stará o paměti a databáze čištění problémy – a reset, v podstatě. Není nic pro vás v tuto chvíli zvládnout. Cílem je získat zpět původní stav nové testy bez překvapení od těch aktuálně spuštěné. Podívejme se, co to znamenalo v fiktivní příklad:

Některé Spec

describe Agent, '#favorite_gadget' do

  it 'returns one item, the favorite gadget of the agent ' do
  # Setup
    agent = Agent.create(name: 'James Bond')
    q = Quartermaster.create(name: 'Q') 
    q.technical_briefing(agent)

  # Exercise    
    favorite_gadget = agent.favorite_gadget
  
  # Verify
    expect(favorite_gadget).to eq 'Walther PPK' 

  # Teardown is for now mostly handled by RSpec itself
  end

end

Jak můžete vidět v tomto příkladu rozdělíme cvičení a ověření fáze jasně od sebe navzájem, zatímco v ostatních výše uvedených fiktivní příkladech, očekávat (agent.favorite_gadget) .na eq ' Walther PKK, máme smíšené obě fáze dohromady. Obě jsou platné scénáře a mají své místo. Také nové linky pomoci vizuálně oddělit, jak je strukturováno.

Těžké něco o testování

Nyní přijde to nejtěžší, co testovat a jak. Podle mého názoru, to je aspekt testování, který je většina matoucí pro nováčky – a tak je pochopitelné! Jsou na jazyk a rámce a často ani netuší, ale co nevíte. Jak psát testy za to? Velmi dobrá otázka.

Bude velmi upřímný, ne – pravděpodobně – a nebudete na nějakou dobu. Chvíli trvá, seznamovat se s touto věcí. Když učitele nebo navštěvovat některé boot camp a tak máte příležitost naučit přímo od zkušených lidí. V takovém případě váš pokrok v tomto oddělení bude jiná, samozřejmě.

Na druhé straně Pokud – jako mnoho dalších tam venku – učíte sami tohle, trpělivost bude klíč. Čtení knih a článků určitě dostane správným směrem, ale myslím, že testování potřebuje hodně pokročilejší dílky na místě, aby vám kompletní smysl a možná ještě důležitější, než se budete cítit pohodlně s ním.

"Dobrá" zpráva je, že to není nic neobvyklého a všichni jsme tam byli. Vytrvalost je důležité. To lze provést, není žádná velká věda, ale chvíli to bude trvat, než můžete napsat aplikaci efektivně od naopak – z hlediska testů, mám na mysli. Pro tuto chvíli zamíříme, bavit se, dělají chyby, psát aplikace, kopírovat návody a kdoví co ještě, dokud světlo žárovka zhasne.

Závěrečné myšlenky

Když píšete jednotlivé testy, chcete jejich objektů, nejjednodušší věc, aby bylo možné dosáhnout cíle – vysoce cílené testy jsou opravdu klíčové. Chcete navrhnout vaší aplikace prostřednictvím velmi jednoduché kroky a pak postupujte podle chyb, ke kterým vám poskytuje testovací sady.

Implementujte pouze, co je nezbytné pro získání aplikace zelené. Ne více ne méně! To je "řízené" část vývoje řízeného testováním. Vaše práce se řídí potřebami testů.