Id\u017a do:<\/p>\n
- \n
- 1. Czym jest Behavior-Driven Development?<\/a><\/li>\n
- 2. TDD vs. BDD<\/a><\/li>\n
- 3. Keep it simple, czyli zalety BDD<\/a><\/li>\n
- 4. Ciemna strona mocy, czyli BDD w praktyce<\/a><\/li>\n
- 5. Najcz\u0119stsze b\u0142\u0119dy w wykorzystaniu BDD<\/a><\/li>\n
- 6. Czytamy test<\/a><\/li>\n
- 7. BDD a czas<\/a><\/li>\n
- 8. BDD: tak czy nie?<\/a><\/li>\n <\/ol>\n<\/div>\n\n\n
Czym jest Behavior-Driven Development?<\/h2>\n\n\n\n
BBD, czyli Behavior-Driven Development, to zwinny proces rozwoju oprogramowania determinowany zachowaniem, ukierunkowany na spe\u0142nienie okre\u015blonych wymaga\u0144. BDD jest procesem wytwarzania oprogramowania, w kt\u00f3rym dokumentacja i testy s\u0105 pisane w j\u0119zyku naturalnym.<\/strong> W idealnym \u015bwiecie BDD powinno by\u0107 integraln\u0105 cz\u0119\u015bci\u0105 ca\u0142ego cyklu wytwarzania oprogramowania. Funkcjonalno\u015bci powinny by\u0107 opisane w s\u0142u\u017c\u0105cym do tego celu j\u0119zyku Gherkin<\/strong><\/a> jeszcze na etapie zbierania wymaga\u0144 i analizy<\/a>,<\/strong> a nast\u0119pnie wykorzystywane (ewentualnie rozwijane) w fazie projektowania i implementacji. Rozpoczynaj\u0105c testy manualne, tester opiera si\u0119 na istniej\u0105cej dokumentacji, kt\u00f3ra w jasny spos\u00f3b pokazuje mu warunki pocz\u0105tkowe, wszystkie niezb\u0119dne akcje i ich fina\u0142. Nast\u0119pnie na jej podstawie tworzone s\u0105 testy automatyczne z zachowaniem j\u0119zyka naturalnego. Tester otrzymuje zadanie do przetestowania manualnego \/ napisania testu automatycznego i dzi\u0119ki czytelnej formie zapisu wie, czym ma si\u0119 zaj\u0105\u0107, a interpretacja zadania nie powinna by\u0107 problemem. Czy zawsze tak jest? Postaram si\u0119 odpowiedzie\u0107 na to pytanie w dalszej cz\u0119\u015bci.<\/p>\n\n\n\n
TDD vs. BDD<\/h2>\n\n\n\n
Behavior-Driven Development cz\u0119sto jest por\u00f3wnywany do podej\u015bcia TDD. Test-Driven Development<\/a><\/strong> tak\u017ce jest zwinnym procesem testowania oprogramowania. Opiera si\u0119 na powtarzaniu cyklu Red \u2013 Green \u2013 Refactoring. Rozw\u00f3j oprogramowania opiera si\u0119 tu na testach napisanych dla jeszcze nieistniej\u0105cych funkcjonalno\u015bci. Podstawow\u0105 r\u00f3\u017cnic\u0105 mi\u0119dzy BDD od TDD jest wykorzystanie w BDD zrozumia\u0142ego dla wszystkich \u2013 nawet os\u00f3b bez wiedzy technicznej \u2013 j\u0119zyka, co pokazuje przyk\u0142ad poni\u017cej.<\/p>\n\n\n\n
Keep it simple, czyli zalety BDD<\/h2>\n\n\n\n
Oto fragment wymaga\u0144, kt\u00f3re s\u0105 r\u00f3wnocze\u015bnie prawdziwym (nie pseudo-) kodem:<\/p>\n\n\n\n
Scenario: User add article\n\nGiven: User is logged in\n\nWhen: User add new article\n\nThen: Article should be displayed<\/pre>\n\n\n\n
Zalety takiego podej\u015bcia wida\u0107 od razu.<\/strong><\/p>\n\n\n\n
Tak skonstruowana dokumentacja, wykorzystuj\u0105ca j\u0119zyk naturalny, jest dost\u0119pna dla wszystkich w projekcie i wspiera rozw\u00f3j aplikacji na r\u00f3\u017cnych etapach.<\/strong> Cz\u0142onkowie zespo\u0142u mog\u0105 omawia\u0107 j\u0105 na spotkaniach przed implementacj\u0105 i w jej trakcie, a nast\u0119pnie wykorzysta\u0107 w testach automatycznych i raportach (je\u017celi s\u0105 generowane), aby czytelnie zobrazowa\u0107 stan aplikacji. Tak\u017ce osoby niemaj\u0105ce wiedzy technicznej, np. przedstawiciele biznesu, mog\u0105 mie\u0107 wgl\u0105d w to, jakie \u015bcie\u017cki biznesowe s\u0105 pokryte przez testy automatyczne. Dzi\u0119ki temu mog\u0105 sprawdzi\u0107, czy aplikacja od samego pocz\u0105tku jest wytwarzana zgodnie z celem biznesowym.<\/p>\n\n\n\n
Jednak w rzeczywisto\u015bci mo\u017ce to wygl\u0105da\u0107 zupe\u0142nie inaczej.<\/p>\n\n\n\n
Ciemna strona mocy, czyli BDD w praktyce<\/h2>\n\n\n\n
Przejd\u017amy teraz od teorii do praktyki. Czasem za\u0142o\u017cenie projektowe co do stosowania BDD rozmija si\u0119 z realizacj\u0105. Przyk\u0142adowo dzieje si\u0119 tak, gdy podej\u015bcie BDD jest wykorzystywane tylko w przypadku test\u00f3w. W rezultacie BDD przestaje by\u0107 procesem wytwarzania oprogramowania, staj\u0105c si\u0119 jedynie form\u0105 pisania test\u00f3w automatycznych. Jak unika\u0107 takich sytuacji i jakie s\u0105 najcz\u0119stsze przyczyny b\u0142\u0119d\u00f3w w wykorzystaniu Behavior-Driven Development?<\/p>\n\n\n\n
Najcz\u0119stsze b\u0142\u0119dy w wykorzystaniu BDD<\/h2>\n\n\n\n
- \n
- Biznes nie dostarcza gotowych scenariuszy w formie \u201eGiven, When, Then\u201d<\/strong><\/li>\n<\/ul>\n\n\n\n
Powody s\u0105 r\u00f3\u017cne: potrzebny jest dodatkowy czas, a wi\u0119c koszt, brakuje ch\u0119ci lub kompetencje odpowiedzialnych os\u00f3b s\u0105 niewystarczaj\u0105ce. Product Owner<\/a> <\/strong>zazwyczaj dostarcza wymagania w j\u0119zyku najbardziej zrozumia\u0142ym dla niego, a p\u00f3\u017aniejsze t\u0142umaczenie na Gherkin schodzi na dalszy plan. W takiej sytuacji tester nie ma mo\u017cliwo\u015bci skopiowania tekstu i wykorzystania go bezpo\u015brednio w kodzie. Praca, kt\u00f3ra powinna by\u0142a by\u0107 wykonana na du\u017co wcze\u015bniejszym etapie projektowym, spada na testera. Zamiast skupi\u0107 si\u0119 na testowaniu, musi on zaj\u0105\u0107 si\u0119 przepisywaniem wymaga\u0144.<\/p>\n\n\n\n
- \n
- Scenariusz test\u00f3w jest tworzony po czasie<\/strong><\/li>\n<\/ul>\n\n\n\n
Podobnie jak w TDD, tak i w BDD testy powinny prowadzi\u0107 wytwarzanie oprogramowania. Nie mo\u017cna jednak tego osi\u0105gn\u0105\u0107, gdy scenariusz jest tworzony po czasie, a nie, zgodnie ze sztuk\u0105, przed napisaniem danej funkcjonalno\u015bci. Problemem jest r\u00f3wnie\u017c brak r\u00f3wnoleg\u0142ej pracy testera i developera. Je\u017celi scenariusz nie zosta\u0142 dostarczony wcze\u015bniej, tester tworzy go cz\u0119\u015bciowo na podstawie dokumentacji, a cz\u0119\u015bciowo na podstawie tego, co stworzy\u0142 programista. W rezultacie testy dopracowywane s\u0105 dopiero na ko\u0144cu, przed zamkni\u0119ciem Sprintu, a testerzy dwoj\u0105 si\u0119 i troj\u0105, aby przetestowa\u0107 funkcjonalno\u015b\u0107 i zamkn\u0105\u0107 wszystkie zadania.<\/p>\n\n\n\n
- \n
- Biznes nie jest zainteresowany tre\u015bci\u0105 test\u00f3w<\/strong><\/li>\n<\/ul>\n\n\n\n
Pisa\u0142em o tym, \u017ce silnym argumentem, kt\u00f3ry przemawia za stosowaniem BDD, jest mo\u017cliwo\u015b\u0107 czytania takich test\u00f3w przez osoby niemaj\u0105ce wiedzy technicznej. W praktyce nigdy nie spotka\u0142em si\u0119 z tym, aby biznes by\u0142 zainteresowany tre\u015bci\u0105 test\u00f3w. Przedstawiciele biznesu ch\u0119tniej zagl\u0105daj\u0105 do raport\u00f3w i kolorowych wykres\u00f3w. Zazwyczaj Product Owner pyta zesp\u00f3\u0142 o stan aplikacji, o to, czy dana funkcjonalno\u015b\u0107 jest gotowa, czy s\u0105 jakie\u015b b\u0142\u0119dy, kt\u00f3re nale\u017cy poprawi\u0107. Pe\u0142na tre\u015b\u0107 raport\u00f3w z test\u00f3w jest znana tylko testerom, tylko oni je monitoruj\u0105, utrzymuj\u0105, rozwijaj\u0105. Gdyby osoby bez wiedzy technicznej ch\u0119tniej czyta\u0142y testy, komunikacja w projekcie rzeczywi\u015bcie by\u0142aby \u0142atwiejsza. Dodatkowo, takie osoby zyska\u0142yby wiedz\u0119, jak przekazywa\u0107 wymagania w bardziej przyst\u0119pny dla tester\u00f3w spos\u00f3b, co umo\u017cliwi\u0142oby szybszy start projektu.<\/p>\n\n\n\n
Czytamy test<\/h2>\n\n\n\n
Za\u0142\u00f3\u017cmy jednak czysto teoretycznie, \u017ce kto\u015b bez znajomo\u015bci programowania chcia\u0142by zobaczy\u0107, co w testach piszczy. Czy na pewno pe\u0142na forma BDD jest jedynym wyj\u015bciem? Poni\u017cej fragment kodu zapisany w Javie z wykorzystaniem frameworku Serenity BDD (jednak bez wykorzystania jego mo\u017cliwo\u015bci pracy z j\u0119zykiem Gherkin):<\/p>\n\n\n\n
@Test\npublic void itShouldBePossibleToAddNewArticle () {\n \/\/ Given\n loginPageSteps.signInUser(testUser);\n navBarSectionSteps.clickNewPost();\n \/\/ When\n editorPageSteps.addArticle(defaultArticle);\n \/\/ Then\n articlePageSteps.articleShouldBeDisplayed(defaultArticle);\n}\n<\/pre>\n\n\n\nJak wida\u0107, nie potrzeba wiedzy programistycznej, aby z tych kilku linijek kodu zrozumie\u0107, \u017ce potrzebne jest logowanie, dodanie artyku\u0142u oraz sprawdzenie jego widoczno\u015bci. Poni\u017cej raport, jaki zosta\u0142 wygenerowany. Zauwa\u017cmy, \u017ce metody jak np. \u201eclickNewPost()\u201d<\/strong> s\u0105 automatycznie przetwarzane na tekst \u201eClick new post\u201d: <\/strong><\/p>\n\n\n\n
<\/div>\n\n\n\n![\"Testy](\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/09\/2020.10.29_jpro_screen_BDD.png\" "\\"\\"")
<\/figure>\n<\/div>\n\n\n<\/div>\n\n\n\nZwyk\u0142y kod, je\u015bli jest odpowiednio przygotowany, r\u00f3wnie\u017c mo\u017ce by\u0107 w \u0142atwy spos\u00f3b analizowany przez osoby bez znajomo\u015bci programowania. Nie m\u00f3wi\u0105c o narz\u0119dziach, takich jak Serenity BDD czy Allure,<\/strong> kt\u00f3re pomagaj\u0105 wygenerowa\u0107 raporty. Teoretycznie, je\u015bli biblioteka krok\u00f3w jest dobrze rozbudowana, to nawet osoba bez wiedzy programistycznej mog\u0142aby dodawa\u0107 kolejne testy. Ten argument jest jednak trudny do spe\u0142nienia, poniewa\u017c zazwyczaj trzeba doda\u0107 tak\u017ce nowe metody ponad te, kt\u00f3re ju\u017c istniej\u0105. Zwykle mo\u017cna wesprze\u0107 si\u0119 cz\u0119\u015bciowo istniej\u0105c\u0105 implementacj\u0105, ale tu ju\u017c jest niezb\u0119dna znajomo\u015b\u0107 programowania.<\/p>\n\n\n\n
BDD a czas<\/h2>\n\n\n\n
Pisa\u0142em o tym, jak wa\u017cne jest, aby podej\u015bcie BDD stosowa\u0107 wy\u0142\u0105cznie ca\u0142o\u015bciowo, na ka\u017cdym etapie. Jest jeszcze jeden bardzo wa\u017cny argument, kt\u00f3ry w mojej ocenie przemawia na niekorzy\u015b\u0107 stosowania BDD w samych testach \u2013 czas. BDD nak\u0142ada kolejn\u0105 warstw\u0119 abstrakcji w tworzonym kodzie, a to z kolei wymaga po\u015bwi\u0119cenia dodatkowego czasu na jej zrozumienie, stworzenie i utrzymanie. Trzeba wi\u0119c albo dodatkowych os\u00f3b w projekcie, albo testerzy, zamiast tworzy\u0107 nowe testy oraz na bie\u017c\u0105co utrzymywa\u0107 istniej\u0105ce, zajmuj\u0105 si\u0119 piel\u0119gnacj\u0105 BDD, tak aby testy by\u0142y czytelne dla os\u00f3b\u2026 kt\u00f3re w rzeczywisto\u015bci ich nie czytaj\u0105.<\/p>\n\n\n\n
BDD: tak czy nie?<\/h2>\n\n\n\n
BDD sta\u0142o si\u0119 has\u0142em modnym, szeroko reklamowanym i obecnie Internet p\u0119ka w szwach od tre\u015bci zachwalaj\u0105cych to podej\u015bcie. Decyzja o wykorzystaniu BDD (czy jakiegokolwiek innego podej\u015bcia) w projekcie nie powinna by\u0107 jednak podejmowana z powodu ch\u0119ci pod\u0105\u017cania za mod\u0105, ale na podstawie dog\u0142\u0119bnej analizy. Problemem mo\u017ce by\u0107 r\u00f3wnie\u017c sytuacja, gdy metodologia BDD jest stosowana cz\u0119\u015bciowo. BDD spe\u0142ni swoje zadania, je\u015bli b\u0119dzie implementowane w\u0142a\u015bciwie w ca\u0142o\u015bciowym procesie wytwarzania oprogramowania, zatem ju\u017c od momentu zbierania wymaga\u0144.<\/strong> Je\u017celi chcemy z niego korzysta\u0107 tylko w automatyzacji test\u00f3w, bez przeprowadzenia dog\u0142\u0119bnej analizy, BDD niekoniecznie musi okaza\u0107 si\u0119 dobrym rozwi\u0105zaniem w ka\u017cdym projekcie. W du\u017cym uproszczeniu, je\u017celi celem test\u00f3w ma by\u0107 poruszanie myszk\u0105 i wpisywanie tekstu, z \u0142atwo\u015bci\u0105 mo\u017cna znale\u017a\u0107 inne narz\u0119dzia, kt\u00f3re zrobi\u0105 to r\u00f3wnie dobrze, oszcz\u0119dzaj\u0105c przy tym sporo czasu. To moja prywatna opinia zebrana w czasie r\u00f3\u017cnych do\u015bwiadcze\u0144 w karierze testera. Wierz\u0119 jednak, \u017ce nie brakuje przyk\u0142ad\u00f3w poprawnej implementacji BDD, a m\u00f3j tekst tak\u017ce przyczyni si\u0119 do wzrostu \u015bwiadomo\u015bci w tym zakresie.<\/p>\n\n\n\n
Q&A<\/h3>\n\n\n\n
Pytanie: <\/strong><\/p>\n\n\n\n
\u201eJe\u017celi chcemy z niego korzysta\u0107 tylko w automatyzacji test\u00f3w, bez przeprowadzenia dog\u0142\u0119bnej analizy, BDD niekoniecznie musi okaza\u0107 si\u0119 dobrym rozwi\u0105zaniem w ka\u017cdym projekcie. W du\u017cym uproszczeniu, je\u017celi celem test\u00f3w ma by\u0107 poruszanie myszk\u0105 i wpisywanie tekstu, z \u0142atwo\u015bci\u0105 mo\u017cna znale\u017a\u0107 inne narz\u0119dzia, kt\u00f3re zrobi\u0105 to r\u00f3wnie dobrze, oszcz\u0119dzaj\u0105c przy tym sporo czasu. To moja prywatna opinia zebrana w czasie r\u00f3\u017cnych do\u015bwiadcze\u0144 w karierze testera. Wierz\u0119 jednak, \u017ce nie brakuje przyk\u0142ad\u00f3w poprawnej implementacji BDD, a m\u00f3j tekst tak\u017ce przyczyni si\u0119 do wzrostu \u015bwiadomo\u015bci w tym zakresie.\u201d<\/p>\n\n\n\n
Jakie narz\u0119dzia np.? Dopiero poznaje \u015bwiat automatyzacji i zaintrygowa\u0142a mnie Twoja opinia. Najcz\u0119\u015bciej spotykam si\u0119 z pisaniem scenariuszy w sk\u0142adni Gherkina (Cucumber \/ JBehave) a potem mapowanie step\u00f3w i dopiero implementacja metod na elementach strony \u2013 jest to ca\u0142kiem wygodne \u2013 jakie mamy alternatywy?<\/p>\n\n\n\n
Odpowied\u017a: <\/strong><\/p>\n\n\n\n
Przyk\u0142adowe narz\u0119dzia to np. czyste Selenium. Gdyby\u015b jednak chcia\u0142 korzysta\u0107 z jakiego\u015b wrappera, to zdecydowanie polecam Ci Selenide \u2013 w zespole testerskim Inetum to narz\u0119dzie jest bardzo lubiane. Do raport\u00f3w dobrym rozwi\u0105zaniem b\u0119dzie Allure.<\/p>\n\n\n\n
W 3 krokach, kt\u00f3re opisa\u0142e\u015b, pierwsze 2 mo\u017cna scali\u0107. Scenariusz piszesz od razu w Javie.<\/p>\n\n\n\n
Podam Ci przyk\u0142ad.<\/p>\n\n\n\n
1. Rozpisujesz testy, dodaj\u0105c czytelne nazwy<\/strong><\/strong><\/p>\n\n\n\n
@Test\npublic void itShouldBePossibleToAddComment() { \n} <\/pre>\n\n\n\n2. Dodajesz Given When Then<\/strong><\/p>\n\n\n\n
@Test\npublic void itShouldBePossibleToAddComment() {\n \/\/Given\n \n \/\/When\n\n \/\/Then\n}\n\n<\/pre>\n\n\n\n3. Rozpisujesz scenariusz w Javie<\/strong><\/p>\n\n\n\n
@Test\npublic void itShouldBePossibleToAddComment() {\n \/\/Given\n articlePage.pageIsOpened();\n\n \/\/When\n articlePage.addComment(comment);\n\n \/\/Then\n articlePage.commentShouldBeDisplayed();\n}\n<\/pre>\n\n\n\n4. Implementujesz metody z kroku 3.
<\/strong><\/p>\n\n\n\nTaki kod powinna zrozumie\u0107 tak\u017ce osoba nietechniczna. A gdyby by\u0142o to problemem, to w Allure istnieje adnotacja @Step. I teraz je\u015bli do metody:<\/p>\n\n\n\n
commentShouldBeDisplayed();<\/p>\n\n\n\n
dodasz adnotacj\u0119 @Step(\u201eKomentarz powinien by\u0107 widoczny\u201d)<\/p>\n\n\n\n
to kod b\u0119dzie wygl\u0105da\u0142 tak:<\/p>\n\n\n\n
Public\u00a0class\u00a0ArticlePage\u00a0{\n\n@Step(\u201eKomentarz\u00a0powinien\u00a0by\u0107\u00a0widoczny\u201d)\n\npublic\u00a0void\u00a0commentShouldBeDisplayed()\u00a0{\n\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/implementacja\u00a0metody\n\n}\n\n}<\/pre>\n\n\n\nA w raporcie Allure ten krok b\u0119dzie widoczny jako \u201eKomentarz powinien by\u0107 widoczny\u201d.<\/p>\n\n\n\n
Przerobi\u0142em przyk\u0142adowy raport, \u017ceby lepiej to zobrazowa\u0107:<\/p>\n\n\n\n
<\/div>\n\n\n\n![\"Allure\"](\"https:\/\/nearshore-it.eu\/wp-content\/uploads\/2024\/09\/jpro_screen.jpg\" "\\"\\"")
<\/figure>\n<\/div>\n\n\n<\/div>\n\n\n\nPrzydatne linki:<\/p>\n\n\n
\n- \n
- demo.qameta.io\/allure\/<\/a><\/li>\n
- selenide.org<\/a><\/li>\n<\/ul>\n<\/div>","protected":false},"excerpt":{"rendered":"
BDD to modne poj\u0119cie, kt\u00f3re robi coraz wi\u0119ksz\u0105 karier\u0119. Behavior-Driven Development to zwinny proces wytwarzania oprogramowania, kt\u00f3ry w za\u0142o\u017ceniu zespo\u0142owi developerskiemu u\u0142atwia komunikacj\u0119 i wsp\u00f3\u0142prac\u0119 z biznesem, a przedstawicielom biznesu zapewnia kontrol\u0119 nad projektem. Czy tak jest w praktyce? W tek\u015bcie wyja\u015bniam, czym jest Behavior-Driven Development, czym r\u00f3\u017cni si\u0119 od TDD oraz jakie s\u0105 najcz\u0119stsze b\u0142\u0119dy z nim zwi\u0105zane.<\/p>\n","protected":false},"author":142,"featured_media":29223,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"iawp_total_views":1066,"footnotes":""},"categories":[1,582],"tags":[562],"offering":[522],"class_list":["post-29215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artykuly","category-technologie","tag-qa","offering-tech-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/users\/142"}],"replies":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/comments?post=29215"}],"version-history":[{"count":7,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29215\/revisions"}],"predecessor-version":[{"id":33835,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/posts\/29215\/revisions\/33835"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media\/29223"}],"wp:attachment":[{"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/media?parent=29215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/categories?post=29215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/tags?post=29215"},{"taxonomy":"offering","embeddable":true,"href":"https:\/\/nearshore-it.eu\/pl\/wp-json\/wp\/v2\/offering?post=29215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- selenide.org<\/a><\/li>\n<\/ul>\n<\/div>","protected":false},"excerpt":{"rendered":"
- demo.qameta.io\/allure\/<\/a><\/li>\n
- Biznes nie jest zainteresowany tre\u015bci\u0105 test\u00f3w<\/strong><\/li>\n<\/ul>\n\n\n\n
- Scenariusz test\u00f3w jest tworzony po czasie<\/strong><\/li>\n<\/ul>\n\n\n\n
- 2. TDD vs. BDD<\/a><\/li>\n