Folding The Design Space @SoCraTes Germany 9 August 2014
•Descargar como ODP, PDF•
6 recomendaciones•1,188 vistas
This talk is about how you can use specification by example to write bottom-up TDD. I use TDD as if you meant it as the extreme classicist TDD aproach for showing how you can grow your systems bottom-up. See here the flipchart pictures from during the presentation: http://t.co/icWxBzxQDr http://t.co/zI66uvYbLW http://t.co/Yy1JCJ2AZp See here the codebase: https://github.com/adi-bolb/FoldingTheSoftwareDesignSpace/commits/01-bottom-up-specification-by-example?page=2 Picture from during the session: https://www.flickr.com/photos/sebastian_bergmann/14684033197/in/set-72157646302093521
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (8)
Más de Adi Bolboaca
Más de Adi Bolboaca (20)
Último
Último (20)
Folding The Design Space @SoCraTes Germany 9 August 2014
- 1. Folding the Design Space Case Study: TDD with Specification by Example www.mozaicworks.com
- 2. Me Adi Bolboacă Programmer Organizational & Technical Trainer & Coach www.mozaicworks.com
- 4. TDD As if you Meant It www.mozaicworks.com 1) Write exactly one failing test 2) Make the test pass by writing implementation code in the test method 3) Create a new implementation method by: a) Extracting implementation code to a new method in the test class b) Moving implementation code into an existing implementation method from the test class 4) Create implementation classes to provide a destination for extracting a method in the test class 5) When necessary move implementation methods into implementation classes 6) Refactor as required
- 5. Classicist TDD Prefer writing state tests Usually start bottom-up Do not use test doubles unless necessary www.mozaicworks.com
- 6. Mockist TDD Prefer writing collaboration tests Usually start top-down Always test in isolation Use only one mock at a time for a test www.mozaicworks.com
- 7. Specification by Example [...]Defining requirements and business- oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements. [http://en.wikipedia.org/wiki/Specification_by_example] www.mozaicworks.com
- 8. Problem: Conway's Game of Life www.mozaicworks.com Having an infinite 2D orthogonal universe Being given an initial generation called a seed The following rules are applied simultaneously A live cell having less than 2 live neighbors dies A live cell having 2 or 3 live neighbors lives A live cell having more than 3 neighbors dies A dead cell having 3 neighbors becomes alive
- 9. Purposes of the session I care about specifications and I don't care about representation Have the cleanest design possible with highly cohesive structures Use real life examples as specifications www.mozaicworks.com
- 10. Incremental design I want to introduce one notion at a time. www.mozaicworks.com
- 11. The visible notions from Conway's Game of Life Cell Board Universe Life state Generation Set of rules Neighbourhood www.mozaicworks.com
- 12. Start with Incremental design Simplify the problem Introduce only one notion at a time Find the main functionality: Tick() www.mozaicworks.com
- 13. Question What would the simplest first step be? www.mozaicworks.com
- 16. Requirements From real life examples “Specification by Example” www.mozaicworks.com
- 17. Conclusions When the solution is less known TDD as if you meant it is useful Bottom-up TDD is useful to grow a system You need to refactor more with TDD bottom-up The design increments are smaller bottom-up www.mozaicworks.com
- 20. Enterprise Agile Architect Role Contact me Unit testing workshop Remote pair-programming TDD workshop Refactoring workshop Legacy code workshop Legacy code retreat Code retreat www.mozaicworks.com
- 21. Enterprise Agile Architect Role Extend your mentoring & training capacity Accelerate learning through communities of practice Grow your functional leaders and top talents http://www.mozaicworks.com adrian.bolboaca@mozaicworks.com @adibolb