Test-Driven Development: Rozbudowany samouczek (nieoficjalne tłumaczenie)
Test-Driven Development: Rozbudowany samouczek (nieoficjalne tłumaczenie)
O Książce
Polska wersja rewelacyjnej książki o TDD (oryginał tutaj). Książka jest streszczeniem wielu publikacji uznanych autorytetów IT takich jak Kent Beck, Martin Fowler czy Robert C. Martin. Jednocześnie przystępny język i przykłady z życia codziennego czynią książkę bardzo atrakcyjną - zarówno dla osób rozpoczynających swoją przygodę z programowaniem, jak i starych wyjadaczy.
O Autorach
Spis treści
-
Przedmowa
- Dedykacja
- Podziękowania!
-
O przykładach kodu
- Uwagi dla programistów języka C#
- Uwagi dla programistów języka Java
-
Część 1: Same podstawy
-
Motywacja – pierwszy krok w uczeniu się TDD
- Jakie jest TDD?
- Zaczynajmy !
-
Niezbędne narzędzia
- Test framework
- Framework do mockowania
- Generator wartości anonimizowanych
- Podsumowanie
-
To nie (tylko) test
- Kiedy test staje się czymś więcej
- Testy w świecie programistów
- Raczej specyfikacja niż zbiór testów
- Różnice między “wykonywalnymi” specyfikacjami i tymi “tradycyjnymi”
-
Programowanie poprzedzone wymaganiem (Wymaganie-najpierw)
- Po co pisać specyfikację po fakcie?
- “Najpierw-test” oznacza patrzenie na niepowodzenie
- “Test-Po” często kończy jako “Test-Nigdy”
- “Test-Po” często prowadzi do ponownego projektowania
- Podsumowanie
-
Poćwiczmy to, czego się właśnie nauczyliśmy
- Pozwól mi opowiedzieć sobie historię
- Akt 1: Samochód
- Akt 2: Tytuł dla Klienta
- Akt 3: Test-Driven Development
- Epilog
- Odnajdźmy się odrobinę
-
How to start?
- Start with a good name
- Start by filling the GIVEN-WHEN-THEN structure with the obvious
- Start from the end
- Start by invoking a method if you have one
- Summary
-
How is TDD about analysis and what does “GIVEN-WHEN-THEN” mean?
- Is there really a commonality between analysis and TDD?
- Gherkin
- TODO list… again!
-
What is the scope of a unit-level Statement in TDD?
- Scope and level
- On what level do we specify our software?
- What should be the functional scope of a single Statement?
- Failing to adhere to the three rules
- How many assertions do I need?
- Summary
-
Developing a TDD style and Constrained Non-Determinism
- A style?
- Principle: Tests As Specification
- First technique: Anonymous Input
- Second technique: Derived Values
- Third technique: Distinct Generated Values
- Fourth technique: Constant Specification
- Summary of the example
- Constrained non-determinism
- Summary
-
Specifying functional boundaries and conditions
- Sometimes, an anonymous value is not enough
- Exceptions to the rule
- Rules valid within boundaries
- Combination of boundaries – ranges
- Summary
-
Driving the implementation from Specification
- Type the obvious implementation
- Fake it (‘til you make it)
- Triangulate
- Summary
-
Motywacja – pierwszy krok w uczeniu się TDD
-
Part 2: Object-Oriented World
-
On Object Composability
- Another task for Johnny and Benjamin
- A Quick Retrospective
-
Telling, not asking
- Contractors
- A Quick Retrospective
-
The need for mock objects
- Composability… again!
-
Why do we need composability?
- Pre-object-oriented approaches
- Object-oriented programming to the rescue!
- The power of composition
- Summary – are you still with me?
-
Web, messages and protocols
- So, again, what does it mean to compose objects?
- Alarms, again!
- Summary
-
Composing a web of objects
- Three important questions
- A preview of all three answers
- When are objects composed?
-
How does a sender obtain a reference to a recipient (i.e. how connections are made)?
- Receive as constructor parameter
- Receive inside a message (i.e. as a method parameter)
- Receive in response to a message (i.e. as method return value)
- Receive as a registered observer
-
Where are objects composed?
- Composition Root
- Factories
- Summary
-
Interfaces
- Classes vs interfaces
- Events/callbacks vs interfaces – few words on roles
- Small interfaces
-
Protocols
- Protocols exist
- Protocol stability
- Craft messages to reflect sender’s intention
- Model interactions after the problem domain
- Message recipients should be told what to do, instead of being asked for information
- Most of the getters should be removed, return values should be avoided
- Protocols should be small and abstract
- Summary
-
Classes
- Single Responsibility Principle
- Static recipients
- Summary
-
Object Composition as a Language
- More readable composition root
- Refactoring for readability
- Composition as a language
- The significance of a higher-level language
- Some advice
- Summary
-
Value Objects
- What is a value?
- Example: money and names
-
Value object anatomy
- Class signature
- Hidden data
- Hidden constructor
- String conversion methods
- Equality members
- The return of investment
- Summary
-
Aspects of value objects design
- Immutability
- Handling of variability
- Special values
- Value types and Tell Don’t Ask
- Summary
-
On Object Composability
-
Part 3: TDD in Object-Oriented World
-
Mock Objects as a testing tool
- A backing example
- Interfaces
- Protocols
- Roles
- Behaviors
- Filling in the roles
- Using a mock channel
- Mocks as yet another context
- Summary
-
Test-first using mock objects
- How to start? – with mock objects
- Responsibility and Responsibility
- Channel and DataDispatch one more time
- The first behavior
- Second behavior – specifying an error
- Summary
-
Test-driving at the input boundary
- Fixing the ticket office
- Initial objects
- Bootstrap
- Writing the first Statement
- Summary
- THIS IS ALL I HAVE FOR NOW. WHAT FOLLOWS IS RAW, UNORDERED MATERIAL THAT’S NOT YET READY TO BE CONSUMED AS PART OF THIS TUTORIAL
- Test-driving at the input boundary - a retrospective
-
Mock objects as a design tool
- Outside-in development
- Worked example
- Programming by intention
- Responsibility-Driven Design
- Specifying factories
-
What not to mock?
- Internals
- How to use value objects in Statements?
- How to specify value objects?
- Terminal nodes in object graph
-
Guidance of test smells
- Long Statements
- Lots of stubbing
- Specifying private members
- Mocking third party
-
Revisiting topics from chapter 1
- Constrained non-determinism in OO world
- Behavioral boundaries
- Triangulation
-
Maintainable mock-based Statements
- Setup and teardown
- Refactoring mock code
-
Mock Objects as a testing tool
-
Part 4: Application architecture
- On stable/architectural boundaries
-
Ports and adapters
- Physical separation of layers
-
What goes into application?
- Application and other layers
-
What goes into ports?
- Data transfer objects
- Ports are not a layer
-
Part 5: TDD on application architecture level
-
Designing automation layer
- Adapting screenplay pattern
- Driver
- Actors
- Data builders
-
Further Reading
- Motivation – the first step to learning TDD
- The Essential Tools
- Value Objects
-
Designing automation layer
- Notatki
60-dniowa Gwarancja 100% Satysfakcji Leanpub
W ciągu 60 dni od zakupu możesz otrzymać 100% zwrotu kosztów za każdy zakup na Leanpub, w dwóch kliknięciach.
Technicznie rzecz biorąc, jest to dla nas ryzykowne, ponieważ i tak będziesz mieć pliki książki lub kursu. Jednak jesteśmy tak pewni naszych produktów i usług oraz naszych autorów i czytelników, że z przyjemnością oferujemy pełną gwarancję zwrotu pieniędzy za wszystko, co sprzedajemy.
O tym, jak dobre jest coś, możesz przekonać się tylko próbując, a dzięki naszej 100% gwarancji zwrotu pieniędzy, dosłownie nie ma żadnego ryzyka!
Więc nie ma powodu, żeby nie kliknąć przycisku Dodaj do Koszyka, prawda?
Zobacz pełne warunki...
Zarabiaj 8$ przy zakupie za 10$ i 16$ przy zakupie za 20$
Wypłacamy 80% tantiem od zakupów o wartości 7,99$ lub więcej oraz 80% tantiem minus opłata 50 centów od zakupów między 0,99$ a 7,98$. Zarabiasz 8$ przy sprzedaży za 10$ i 16$ przy sprzedaży za 20$. Więc jeśli sprzedamy 5000 niezwróconych kopii twojej książki po 20$, zarobisz 80 000$.
(Tak, niektórzy autorzy już zarobili znacznie więcej na Leanpub.)
W rzeczywistości autorzy zarobili jużponad 14 milionów dolarówpisząc, publikując i sprzedając na Leanpub.
Dowiedz się więcej o pisaniu na Leanpub
Darmowe Aktualizacje. Bez DRM.
Kupując książkę na Leanpub, otrzymujesz darmowe aktualizacje tak długo, jak autor aktualizuje książkę! Wielu autorów korzysta z Leanpub do publikowania książek w trakcie ich pisania. Wszyscy czytelnicy otrzymują darmowe aktualizacje, niezależnie od tego, kiedy kupili książkę i ile za nią zapłacili (włącznie z darmowymi).
Większość książek Leanpub jest dostępna w formacie PDF (na komputery) oraz EPUB (na telefony, tablety i Kindle). Formaty dostępne dla danej książki są pokazane w prawym górnym rogu tej strony.
Co więcej, książki Leanpub nie posiadają żadnych nonsensownych zabezpieczeń DRM, więc możesz je łatwo czytać na każdym obsługiwanym urządzeniu.
Dowiedz się więcej o formatach ebooków Leanpub i gdzie można je czytać
