Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

Problemy, strategie, taktyki, techniki i narzędzia oraz: Behavior Driven Development i Specification by Example, Architektura Ports & Adapters
by

Sławek Sobótka

on 10 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

B
ehavior
D
riven
D
evelopment,
czyli
Agile 2.0
Strategia testowania
co?
jak bardzo?
w jaki sposób?
... testować
Scrum
Product backlog
Historyjka
użytkownika
Development
Testing
Deployment
Obsługa zamówienia

Jako
klient sklepu
Chcę
dodać produkt do koszyka
W celu
złożenia zamówienia

Mając daną
listę produktów
Gdy
dodaję produkt do koszyka
Wówczas
ten produkt powinien
być w koszyku
Programista
Analityk
Ekspert Domenowy
Tester
Projektant
GUI
Remoting
Remoting
Interfejs Webowy
MVC/MVP/MVVM
REST/WebServices/RMI
Infrastruktura
Baza danych
Kolejka komunikatów
Zew. systemy
Uslługa Aplikacyjna
Logika aplikacji
Logika domenowa
Zdarzenie
domenowe
Polityka
Zespółl
Klient
Testy end2end (systemowe/komponentowe)
Testy jednostkowe
Co napędza Twój proces?
wymagania?
testy?
model bazy danych?
Zwinny proces wytwarzania oprogramowania
Jak powinien się zachowywać system z punktu widzenia ludzi, których problemy rozwiązuje?
skrypt
BDD = DDD + TDD + Scrum
stabilność wymagań, klarowność, ogólność
Działająca aplikacja
open "http://..."
pause "2000"
clickAndWait "link=Browse"
pause "3000"
assertTitle "Browsing products"
clickAndWait "link=Gizmo 2.0"
assertTitle "Product details - Gizmo 2.0"
click "//input[@name='buy' and @value='1']"
type "quantity", "6"
clickAndWait "//input[@value='Add to cart']"
assertTitle "My shopping cart"
Ale ...
Scrum
tylko zarządzanie
nie jest związany z softwarem
brak technik / praktyk (jak w XP)
*
+
Agregat
Repozytorium
Usługa
domenowa
Fabryka
Encja
Automatyzacja
Workflow
Specification by Example
kroki JBehave:
Scenario: transfer money
Given
I have $100 in checking
I have $20 in savings
When
I go to the transfer form
I select "Checking" from "Source Account"
I select "Savings" from "Target Account"
I fill in "Amount" with "15"
I press "Execute Transfer"
Then
I should see that I have $85 in checking
I should see that I have $35 in savings
kod == model domeny
wymagania
ekspert
modelarz
rola (nie stanowisko)
model wymagań != model domeny
UWAGA
5
10
15
?
==
źZródłlo: Gojko Adzic 2011 "Specification by Example: How Successful Teams Deliver the Right Software"
Czego mama nigdy nie mówiła Ci na temat testowania automatycznego
problemy
strategie
taktyki
techniki
narzędzia
Sawomir Sobótka
Czego mama nigdy nie mówiła Ci na temat testowania automatycznego
problemy
strategie
taktyki
techniki
narzęedzia

Slawomir Sobótka
Problemy
Eksplozja kombinatoryczna przypadków
Smells: Delikatne testy (fragile), Nieczytelne testy
Koszt stworzenia i utrzymania testów
Kosztowne w utrzymaniu skrypty do „wyklikania”
Nieaktualna dokumentacja (nikt jej nie czyta ani nie aktualizuje)
Problem z komunikacja - brak zrozumienia celów biznesowych, biznes nie rozumie systemu
Architektura wspierajca testability

Customer orders products

Narrative:
In order to buy interesting
products
As a
customer
I want to browse the available products, pick the ones that I like and
order
them

Scenario:
client puts some products into
baskets
and checks out
Given Products are available
When I add any product to basket
Then Basket should contain 1 item
When I checkout
Then I should be able to
submit
order with 1 product
When I submit the order
Then That order should be
confirmed
Problem: Eksplozja kombinatoryczna przypadków
Strategie:
Mapowanie piramidy testów na warstwy aplikacji
Perfekcja domeny, ogólna zgodno wymaga
Taktyki:
Warstwa Aplikacji – Testy End-to-end – Komponentowe
Warstwa Domenowa – Testy jednostkowe
Abstrakcje Warstwy Infrastruktury – Testy integracyjne
Zapachy: delikatne i nieczytelne testy
Strategie:
Twórz wykonywalną dokumentację
Operuj słownictwem domenowym
Taktyki:
Techniki:
Testowanie niezmienników Agregatów
Assembler Agregatów
Assert Object
Testowanie Serwisów Domenowych w stylu funkcyjnym
Jak tworzyć zaślepki: Command-Mock, Query-Stub
Czytelnosc
VS
metody assemblera nie sa 1-linijkowe
assembler podnosi poziom abstrakcji
"strefa zgniotu"
NIGDY nie zaczynaj od assemblera
unikaj "szumu" - tylko istotne dla hipotezy parametry
Black-box
Query
command
There is no spoon
Funktor nie potrzebuje dublerów
Problem: Koszt stworzenia i utrzymania testow
Strategie:
Czy potrzebujesz 80%?
Mapowanie piramidy testów na warstwy aplikacji
Perfekcja domeny, ogólna zgodność wymagań
Obniżanie kosztów poprzez unikanie zbędnej pracy
Taktyki:
Oszczędzaj na pracy z serverem i klikaniu w UI
Skupiaj testowane hipotezy wokół celów biznesowych - one raczej* sie nie zmieniaja (pojawiaja sie nowe)
Techniki:
Tworz "strefy zgniotu": warstwy testow, Assemblery, Assert Objecty
Problem: kosztowne w utrzymaniu "skrypty klikania"
Nieaktualna dokumentacja, problem z komunikacja
Strategie:
Skupiaj dokumentację wokół celów biznesowych i flow użytkownika
Orientuj się na Flow a nie na skrypt UI
Orientuj się na Specyfikację a nie Flow
Taktyki:
Dwuwarstwowe Historyjki akceptacyjne
Trójwarstwowe Wykonywalne Specyfikacje
Struktura Given-When-Then: W proponuje dev, GT definiuje ekspert
Techniki:
Agenty abstrahujące od protokołu komunikacyjnego
Struktura Given-When-Then: W przez UI, GT niżej
Niektóre specyfikacje testuj jednostkowo w warstwie domeny
Narzedzia:
JBehave, Selenium, Spring Remoting
Scenario: transfer money
Given
I have $100 in checking
I have $20 in savings
When
I go to the transfer form
I select "Checking" from "Source Account"
I select "Savings" from "Target Account"
I fill in "Amount" with "15"
I press "Execute Transfer"
Then
I should see that I have $85 in checking
I should see that I have $35 in savings
open "http://..."
pause "2000"
clickAndWait "link=Browse"
pause "3000"
assertTitle "Browsing products"
clickAndWait "link=Gizmo 2.0"
assertTitle "Product details - Gizmo 2.0"
click "//input[@name='buy' and @value='1']"
type "quantity", "6"
clickAndWait "//input[@value='Add to cart']"
assertTitle "My shopping cart"
Alternatywne scenariusze dojscia do celu
Flow biznesowy zamiast "protokolu komunikacyjnego"
Cel biznesowy zamiast flow
Sławomir Sobótka
slawomir.sobotka@bottega.com.pl
http://art-of-software.blogspot.com
http://code.google.com/p/ddd-cqrs-sample/
http://ssepp.pl
Czego mama nigdy nie mówiła Ci na temat testowania automatycznego
problemy
strategie
taktyki
techniki
narzęedzia

WHEN
GIVEN+THEN
Skupiaj testowane hipotezy wokół celów biznesowych i flow użytkownika
Testy integracyjne
(abstakcji infrastruktury)
Fake domain
niezależność od technologii
życie w izolacji
Order Invoice BookKeeper
Domain Model
Application Logic
Capability
Operations
Policy
Decision Support
Operational Level
Knowledge Level
Business resources
Potential, possibilities
Low impact of changes
Business state, activity and plans
Utilized possibilities
Medium impact of changes
Goals, rules (law)
Strategies, constraints
High impact of changes
Analytic engines
"Intelligence"
Low impact of changes
Supple Design
Order
BookKeeper
Invoice
<<Aggregate>>
<<Aggregate>>
<<Domain Service>>
Tax Policy
domain operation
closure
<<Factory>>
<<Value Object>>
Immutable
functional
PORTS
ADAPTERS
KERNEL
Impl
implements
PurchaseApplicationService{
<<Interface>>
Services (API)
<<Interface>>
Read API
Modeling
Use Case
User Story
Read Model
<<Interface>>
Repository/DAO
Domain Persistence
ORM (remember about whole Aggregate optimistic locking)
SOA
...
<<Interface>>
Infrastructure
"technical" services
<<Interface>>
Events Publisher
Asynchronous
<<Event>>
<<Event>>
ORM
JDBC
noSQL
Fake/Stub/Mock
JMS
...
Fake/Stub/Mock
WS
REST
Binary
...
Fake/Stub/Mock
<<Event>>
ADAPTERS
PORTS
KERNEL
<<Interface>>
Events Publisher
Asynchronous
<<Event>>
JMS
...
Fake/Stub/Mock
User Story / Use Case Model
protect invariants!
a + b = c
Building Blocks
Product
equivalent
adviser
Discount
assistant:)
PricingPlan
<<Value Object>>
Purchase
<<Aggregate>>
generatePricingPlan(RebatePolicy)
<<Function>>
<<domain service>>
if prices did not change
in the "meantime"
Model says: we can issue and Invoice for just one Order
but we are smart, we can "hack" model by creating FakeOrder that extends Order:)
... but what would Your mom and Domain Expert say?
CRM Bounded Context
Domain does not "leak"
public number is better than DB ID
Story/Case Scenario
TX and Security via AOP
"offered" ports
"required" ports
Snapshot of the current Product
data (ex. price)
Effective cost (including
current Discount)
Can be used as an
Evidence (ex. copyrights)
Different level of abstraction: concepts like Purchase and PricingPlan can be hidden
Architektura Ports & Adapters
Web App
Webservice
REST
JSON
Binary
Listener/
Receptor
Acceptance Scenario
Component Test
Command
+
Handler
<<DTO>>
Full transcript