Automated Tests in Agile based on Serenity BDD - Michał Szybalski

Editor's Notes

• #6: BDD was originally invented by Dan North in the early to mid-2000s as an easier wayto teach and practice Test-Driven Development (TDD). TDD, invented by Kent Beck inthe early days of Agile,10 is a remarkably effective technique that uses unit tests to specify,design, and verify application code. Cała aplikacja budowana jest z komponentów, małymi historyjkami które opowiadają o tym jak powinien zachować się program gdy zajdą pewne okoliczności – z ang. stories. Każde story budowany jest na schemacie given,when,then : given – określa warunki początkowe, przedstawia aktora, zapoznaje odbiorcę z kontekstem historyjki, when – opisuje akcje, występujące zdarzenie, then – informuje o oczekiwanych rezultatach.
• #7: USING EXAMPLES A SHARED UNDERSTANDING SOFTWARE THAT MATTERS Wykorzystanie przykładów na wielu poziomach w celu utworzenia wspólnego zrozumienia i powierzchniowej niepewności Tak by dostarczyć oprogramowanie, które ma znaczenie jest zwinną techniką tworzenia oprogramowania mającą na celu lepszą integrację między programistami, testerami, ale także co bardzo ważne ludźmi biznesu czyli osobami nietechnicznymi ZAŁOŻENIA: ustalenie celów wszystkich zainteresowanych stron potrzebnych do realizacji wizji zdefiniowanie potencjalnych możliwości, które zostaną osiągnięte za pomocą napisanego kodu zaangażowanie stakholderów w proces tworzenia oprogramowania stworzenie przykładów opisujących sposób działania aplikacji automatyzacja wyżej wymienionych przykładów i możliwość jej późniejszego wykorzystania w regresji wykorzystanie mocków w celu umożliwienia symulacji oprogramowania z modułami, które nie zostały jeszcze stworzone
• #9: analizujemy, planujemy i projektujemy tyle, ile naprawdę trzeba • nie tracimy czasu na na wyspecyfikowanie od razu całego zakresu projektu – wymagania i tak będą się pewnie zmieniać • robimy tylko tyle, ile trzeba wszystko, co robimy ma nieść ze sobą realną wartość biznesową • jeśli robimy coś, co tej wartości nie przynosi, warto zająć się czymś innym • jeżeli funkcjonalność pojawia się w projekcie, to znaczy, że jest wartościowa wszyscy uczestnicy projektu powinni odwoływać i myśleć o systemie w ten sam sposób – opisując jego zachowanie tym samym słownictwem dzięki temu zmniejszana jest bariera komunikacyjna między „nietechnicznym” klientem, a „technicznymi” programistami wymagania definiujemy w formie historyjek użytkownika
• #10: Let’s say Chris’s company needs a new module for its accounting software. When Chris wants to add a new feature, the process goes something like this (see figure 1.1): 1 Chris tells a business analyst how he would like the feature to work. 2 The business analyst translates Chris’s requests into a set of requirements forthe developers, describing what the software should do. These requirementsare written in English and stored in a Microsoft Word document. 3 The developer translates the requirements into code and unit tests—written inJava, C#, or some other programming language—in order to implement thenew feature. 4 The tester translates the requirements in the Word document into test cases,and uses them to verify that the new feature meets the requirements. 5 Documentation engineers then translate the working software and code backinto plain English technical and functional documentation. There are many opportunities for information to get lost in translation, be misunderstood,or just be ignored. Chances are that the new module itself may not do exactlywhat was required and that the documentation won’t reflect the initial requirementsthat Chris gave the analyst.
• #11: Chris’s friend Sarah runs another company that just introduced BDD. In a team practicingBDD, the business analysts, developers, and testers collaborate to understandand define the requirements together. They use a common languagethat allows for an easy, less ambiguous path from end-user requirements to usable, automatable tests. Like Chris, Sarah talks to a business analyst about what she wants. To reduce therisk of misunderstandings and hidden assumptions, they talk through concrete examples of what the feature should do. Before work starts on the feature, the business analyst gets together with the developer and tester who will be working on it, and they have a conversation about the feature. In this conversation, they discuss and translate key examples of how the feature should work into a set of requirements written in a structured, English-language format often referred to as Gherkin The developer uses a BDD tool to turn these requirements into a set of automatedtests that run against the application code and help objectively determinewhen a feature is finished. The tester uses the results of these tests as the starting point for manual andexploratory tests. The automated tests act as low-level technical documentation, and provideup-to-date examples of how the system works. Sarah can review the test reports tosee what features have been delivered, and whether they work the way she expected.
• #14: Selenium - a suite of tools to automate web browsers across many platforms. Z jednej strony to bardzo wygodne dla programisty API pozwalające na interakcję z przeglądarką, z drugiej zaś to koncepcja sterowników (ang. driver), które tę bezpośrednią komunikację umożliwiają Doesn’t need a real browser No javascript limitations No need for a server.
• #15: Selenium - a suite of tools to automate web browsers across many platforms. Z jednej strony to bardzo wygodne dla programisty API pozwalające na interakcję z przeglądarką, z drugiej zaś to koncepcja sterowników (ang. driver), które tę bezpośrednią komunikację umożliwiają
• #16: Pozwala na odwzorowanie stron internetowych w klasy, w których metody reprezentują możliwe do wykonania akcje, natomiast pola - elementy na stronie.