Regu\u0142y biznesowe<\/h2>\n
\u017badne testy nie maj\u0105 sensu, je\u017celi nie weryfikuj\u0105 jakiego\u015b systemu. Naszym kodem produkcyjnym b\u0119dzie maszyna z przek\u0105skami, czyli klasyczna TDD Kata.<\/p>\n
Jak dzia\u0142a nasz automat? Dzisiaj zajmiemy si\u0119 tylko cz\u0119\u015bci\u0105 jego funkcji. B\u0119dziemy weryfikowa\u0107 dwie rzeczy:<\/p>\n
- \n
- wrzucamy do niego pieni\u0105dze i mo\u017cemy poprosi\u0107 o ich zwrot<\/li>\n
- kupujemy produkt i otrzymujemy reszt\u0119<\/li>\n<\/ul>\n
Rozszerzon\u0105 wersj\u0119, wraz ze 100% pokryciem testami, znajdziesz na githubie<\/a>.<\/p>\n
Testy, testy i jeszcze wi\u0119cej test\u00f3w<\/h2>\n
Testy jednostkowe<\/h3>\n
Znaj\u0105c wymagania, mo\u017cemy zaj\u0105\u0107 si\u0119 testami. Zaczniemy od najmniej skomplikowanego podej\u015bcia, czyli test\u00f3w jednostkowych.
W tej cz\u0119\u015bci b\u0119dziemy weryfikowa\u0107 zachowanie pojedynczych metod klasy VendingMachine.<\/p>\nNaszym pierwszym testem b\u0119dzie sprawdzenie, czy mo\u017cemy otrzyma\u0107 z powrotem wrzucon\u0105 kwot\u0119:<\/p>\n
[Theory]\n[InlineData(\"1, 1, 1\", \"1, 1, 1\")]\n[InlineData(\"0.25, 0.25, 0.25, 0.25\", \"0.25, 0.25, 0.25, 0.25\")]\npublic void ReturnsAllInsertedCoins(string insertedCoins, string expected)\n{\n var vendingMachine = new VendingMachine();\n vendingMachine.InsertMoney(insertedCoins);\n\n var returnedCoins = vendingMachine.Return();\n\n returnedCoins.Should().Be(expected);\n}<\/pre>\nNa co warto zwr\u00f3ci\u0107 uwag\u0119 w tym fragmencie kodu?
Na pewno na atrybut [InlineData]<\/i>, kt\u00f3ry pozwala przekaza\u0107 nam parametry do testu. Korzystaj\u0105c z niego, definiujemy warto\u015b\u0107 monet wrzuconych do maszyny (parametr insertedCoins<\/i>) oraz oczekiwany rezultat (parametr expected<\/i>).
Nast\u0119pnie tworzymy instancj\u0119 klasy, kt\u00f3r\u0105 testujemy i wywo\u0142ujemy na niej odpowiednie metody.
Na koniec, korzystaj\u0105c z FluentAssertions, weryfikujemy rezultat.
W tym stylu b\u0119d\u0105 utrzymane pozosta\u0142e testy jednostkowe, kt\u00f3re mo\u017cesz zobaczy\u0107 TUTAJ<\/a>.<\/p>\nTesty BDD<\/h3>\n
Przysz\u0142a pora na testy BDD, czyli Behavior Driven Development. Czym r\u00f3\u017cni\u0105 si\u0119 one od test\u00f3w jednostkowych? Przede wszystkim, zmieniamy podej\u015bcie. W tym przypadku, spr\u00f3bujemy od razu zdefiniowa\u0107 ko\u0144cowy scenariusz. Takie scenariusze b\u0119d\u0105 „m\u00f3wi\u0107 w j\u0119zyku biznesu”. To znaczy, \u017ce zamiast weryfikowa\u0107 konkretne metody, spr\u00f3bujemy zapisa\u0107 nasz test w j\u0119zyku zbli\u017conym do naturalnego. Jak wygl\u0105da to w \u201c\u017cywym\u201d kodzie?
Na przyk\u0142ad, w ten spos\u00f3b:<\/p>\nnamespace BDDTests\n{\n namespace ForBuyingProductsWithChange\n {\n public class WhenInsertedMoreMoneyThanPriceOfProduct \n : GivenSubject<VendingMachine, string>\n {\n public WhenInsertedMoreMoneyThanPriceOfProduct()\n {\n Given(() => Subject.InsertMoney(\"1, 0.50\"));\n\n When(() => Subject.GetCola());\n }\n\n [Fact]\n public void ThenGetColaWithChange()\n {\n Result.Should().ContainAll(\"Cola\", \"0.50\");\n }\n }\n }\n}\n<\/pre>\nJak wida\u0107, dzieje si\u0119 tutaj du\u017co wi\u0119cej, ni\u017c we wcze\u015bniejszym przyk\u0142adzie. Spraw\u0119 komplikuje r\u00f3wnie\u017c to, \u017ce korzystamy z biblioteki ChillBDD<\/i>.
Zacznijmy od dw\u00f3ch namespace’\u00f3w<\/i>, kt\u00f3re pozwalaj\u0105 nam dok\u0142adniej opisa\u0107, co dzieje si\u0119 w samym te\u015bcie.
Zwr\u00f3\u0107 uwag\u0119 na dziedziczenie po generycznej klasie GivenSubject<vendingmachine, string=””><\/vendingmachine,><\/i>. Dzi\u0119ki temu korzystamy z w\u0142a\u015bciwo\u015bci Subject<\/i>, kt\u00f3ra jest instancj\u0105 klasy VendingMachine<\/i> oraz z w\u0142a\u015bciwo\u015bci Result<\/i>, kt\u00f3ra jest typu string<\/i> i oczywi\u015bcie, zawiera rezultat. Ok, wszystko pi\u0119knie, ale rezultat czego? I tutaj znowu musimy odwo\u0142a\u0107 si\u0119 do Chill<\/i>. Zapewne zauwa\u017cy\u0142a\u015b lub zauwa\u017cy\u0142e\u015b dwie lambdy w konstruktorze – Given<\/i> oraz When.
To w\u0142a\u015bnie w tym miejscu przygotowujemy dane i wywo\u0142ujemy metod\u0119, kt\u00f3rej rezultat weryfikujemy. When(() => Subject.GetCola()); przypisuje do w\u0142a\u015bciwo\u015bci Result wynik metody GetCola().
Dzi\u0119ki temu, mo\u017cemy opisa\u0107 nasz test, korzystaj\u0105c ze schematu Given – When – Then, gdzie Then jest po prostu weryfikacj\u0105 wyniku.<\/p>\nSzukasz szkolenia dla siebie lub swojego teamu?
Sprawd\u017a nasze zdalne szkolenia dla firm z trenerem NA \u017bYWO<\/a><\/span><\/div>\nTesty mutacyjne<\/h3>\n
Na koniec zupe\u0142nie zmienimy nasz punkt widzenia. Co ciekawe, tym razem nie napiszemy ani linijki kodu! Skorzystamy natomiast z test\u00f3w mutacyjnych i biblioteki Stryker .Net.<\/p>\n
Czym charakteryzuje si\u0119 ten rodzaj test\u00f3w? Przede wszystkim, w ten spos\u00f3b b\u0119dziemy weryfikowa\u0107 jako\u015b\u0107 do tej pory napisanych test\u00f3w.<\/p>\n
Ca\u0142y proces sk\u0142ada si\u0119 z trzech cz\u0119\u015bci:<\/p>\n
1. Stryker .Net wprowadzi do naszego kodu mutanty. Czym s\u0105 mutanty? To nic innego jak zmiany w naszym kodzie. Mog\u0105 to by\u0107 zar\u00f3wno zmiany operatora z > na <, zanegowanie warto\u015bci typu bool, jak i zamiana stringa. Po list\u0119 wszystkich dost\u0119pnych mutacji zapraszam do dokumentacji<\/a>.<\/p>\n
2. W nast\u0119pnym kroku, dla ka\u017cdego wprowadzonego mutanta, Stryker uruchomi nasze testy.<\/p>\n
3. Na koniec procesu otrzymamy raport w formacie html, kt\u00f3ry powie nam, kt\u00f3re mutanty prze\u017cy\u0142y, a kt\u00f3re zosta\u0142y wychwycone przez nasze testy. Mutant, kt\u00f3ry prze\u017cy\u0142 to taka zmiana, kt\u00f3ra nie zepsu\u0142a \u017cadnego z naszych test\u00f3w.<\/p>\n
Jakie wnioski mo\u017cemy wyci\u0105gn\u0105\u0107 z tej procedury? Oczywi\u015bcie, szukamy mutant\u00f3w, kt\u00f3re prze\u017cy\u0142y. Je\u017celi zmiana w kodzie nie zepsu\u0142a chocia\u017c jednego testu, to powinna zapali\u0107 si\u0119 nam czerwona lampka. Skoro mo\u017cemy dowolnie zmienia\u0107 kod, a nasze testy nie s\u0105 w stanie tego wychwyci\u0107, to jako\u015b\u0107 naszych test\u00f3w nie jest najwy\u017csza.<\/p>\n
Sprawd\u017amy, jak zachowaj\u0105 si\u0119 nasze testy w starciu z mutantami.<\/p>\n
W odr\u00f3\u017cnieniu od poprzednich bibliotek, kt\u00f3re mo\u017cemy zainstalowa\u0107 przez Nuget, Stryker .Net instalujemy r\u0119cznie.
Je\u017celi masz zainstalowane .Net Core SDK w wersji wy\u017cszej ni\u017c 2.1 to z linii polece\u0144 wystarczy wywo\u0142a\u0107 instrukcj\u0119:<\/p>\ndotnet tool install -g dotnet-stryker<\/code><\/p>\nNast\u0119pnie, z katalogu z testami, uruchamiamy bibliotek\u0119:<\/p>\n
dotnet stryker --reporters \"['html', 'progress']\"<\/code><\/p>\nPo oko\u0142o minucie powinni\u015bmy zobaczy\u0107 rezultat oraz \u015bcie\u017ck\u0119 do pliku z raportem.
Jego fragment wygl\u0105da w ten spos\u00f3b:<\/p>\n![\"screen\"](\"https:\/\/infoshareacademy.com\/wp-content\/uploads\/2020\/04\/wycinek.png\")
<\/figure>\nJest to cz\u0119\u015b\u0107 metody GetProductWithChange<\/a>, z zaznaczonymi mutantami. Zwr\u00f3\u0107 uwag\u0119 na numer 20 i zmian\u0119, kt\u00f3r\u0105 wprowadzi\u0142 Stryker. Po wprowadzeniu mutanta, kt\u00f3ry zwi\u0119ksza\u0142 ilo\u015b\u0107 produkt\u00f3w po zakupie, nasze testy dalej przechodzi\u0142y. Taka zmiana bardzo szybko doprowadzi do problem\u00f3w poniewa\u017c b\u0119dziemy pr\u00f3bowali sprzeda\u0107 produkt, kt\u00f3rego nie mamy w maszynie.<\/p>\n
Jak powinien wygl\u0105da\u0107 test, kt\u00f3ry wychwyci tak\u0105 zmian\u0119? Oczywi\u015bcie, powinien on sprawdza\u0107 czy ilo\u015b\u0107 produkt\u00f3w zosta\u0142a zmniejszona po jego zakupie. Spr\u00f3buj naprawi\u0107 ten problem w ramach treningu.<\/p>\n
Kiedy stosowa\u0107 dany typ test\u00f3w<\/h2>\n
Wiedz\u0105c ju\u017c, jak wygl\u0105da nasz ma\u0142y wycinek \u015bwiata test\u00f3w, zastan\u00f3wmy si\u0119, kiedy stosowa\u0107 konkretne rodzaje test\u00f3w.<\/p>\n
Testy jednostkowe<\/b> zazwyczaj przynosz\u0105 najwi\u0119cej korzy\u015bci, kiedy weryfikujemy jaki\u015b ma\u0142y, niezale\u017cny wycinek systemu. Czym jest ma\u0142y i niezale\u017cny wycinek? To pytanie jest tematem nieko\u0144cz\u0105cych si\u0119 spor\u00f3w i internetowych wojen. Najprostszym za\u0142o\u017ceniem jest testowanie pojedynczych klas i ich metod. I przy tej definicji zostaniemy.<\/p>\n
Takie testy jest stosunkowo \u0142atwo napisa\u0107, a uruchamiaj\u0105 si\u0119 bardzo szybko. W zwi\u0105zku z tym mo\u017cemy z nich korzysta\u0107 bardzo cz\u0119sto i na bie\u017c\u0105co sprawdza\u0107, czy niczego nie zepsuli\u015bmy.<\/p>\n
BDD<\/b> sprawdza si\u0119 na przyk\u0142ad przy tworzeniu kryteri\u00f3w akceptacyjnych. Konkretne wymagania mo\u017cemy zapisa\u0107 w formie kodu i zadanie uzna\u0107 za sko\u0144czone, kiedy nasz test przechodzi.<\/p>\n
Warto pami\u0119ta\u0107 o tym, \u017ce takie testy b\u0119d\u0105 cz\u0119\u015bci\u0105 kodu \u017ar\u00f3d\u0142owego naszej aplikacji. W zwi\u0105zku z tym przedyskutuj wcze\u015bniej z zespo\u0142em, czy planujecie takie testy tworzy\u0107 oraz jakich bibliotek do tego u\u017cyjecie.<\/p>\n
Testy mutacyjne<\/b> przydatne s\u0105 w ka\u017cdym momencie. Z racji tego, \u017ce bibliotek\u0119 do takich test\u00f3w mo\u017cemy zainstalowa\u0107 lokalnie i nie musimy w tej sprawie konsultowa\u0107 si\u0119 ze swoim zespo\u0142em. Jedynym wymogiem jest po prostu to, \u017ce piszecie testy. Je\u017celi nie macie \u017cadnych test\u00f3w w projekcie (co, niestety si\u0119 zdarza), to taka metoda weryfikacji nie b\u0119dzie mia\u0142a \u017cadnego sensu.<\/p>\n
Podsumowanie<\/h2>\n
Jak wida\u0107, \u015bwiat test\u00f3w jest niesamowicie bogaty, a zacz\u0105\u0107 jest bardzo \u0142atwo. Wystarczy podstawowa znajomo\u015b\u0107 j\u0119zyka programowania i kompatybilnej z nim biblioteki. Zazwyczaj, w komercyjnych projektach, b\u0119dzie ju\u017c do tego dost\u0119pna infrastruktura wi\u0119c nie trzeba si\u0119 b\u0119dzie troszczy\u0107 o wyb\u00f3r bibliotek oraz ich konfiguracj\u0119.<\/p>\n
Je\u017celi szukasz czego\u015b bardziej skomplikowanego, mo\u017cesz zapozna\u0107 si\u0119 tematem Property-Based testing<\/a> dla tej samej maszyny z przek\u0105skami.<\/p>\n
Autor:<\/strong>
Jakub Ciechowski<\/a><\/strong><\/p>\n![\"Jakub](\"https:\/\/infoshareacademy.com\/wp-content\/uploads\/2020\/04\/kuba-a-removebg-preview-e1587077774552.png\")
<\/figure>\nProgramista C# w Aspire Systems Poland<\/a>. Mi\u0142o\u015bnik DDD i \u015bcis\u0142ej wsp\u00f3\u0142pracy z biznesem. Wielki fan kawy, kt\u00f3ry nie wyobra\u017ca sobie dnia, bez dzbanka naparu z drippera.<\/p>\n
Przeczytaj tak\u017ce:
Klient HTTP i obs\u0142uga API<\/a><\/span><\/div>\n\n\n<\/p>\n\n\n