Practiced agile developer with tdd & bdd


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Practiced agile developer with tdd & bdd

  1. 1. Practiced AgileDeveloper with TDD andBDDby Sakares SaengkaewSoftware Development and Quality Improvement,Asian Institute of Technology
  2. 2. How many hours testing of yoursoftware? When will you performtesting? What happens?● 8 hours?● 10 % of project work hours.● before deployment 5 days and some bugsstill be unsolved left.● complicate unsolvable bug.● Need more time to debug.● Just show to customer and wish they will notsee unexpected scene.
  3. 3. How should we make itbetter?- Change the way of codingby TDD !
  4. 4. Whats TDD ?- abbreviated from "Test Driven Development".- a programming technique based on a verysimple rule :Only ever write code to fix a failing test.
  5. 5. Whats TDD ?- Test first, then code and design afterward.
  6. 6. Whats TDD ?- But Its not finished yet.- We call it refactoring to better communicatethat the last step is about transforming thecurrent design toward a better design.
  7. 7. How to ?- Using Unit Test. For example, JUnit in Java,BoostTest in C++ or UnitTest in Ruby on Rails.- Perform Red-Green-Refactor principle.
  8. 8. Red-Green-Refactor- Firstly, write a test. Hence, it failed (Red)since there is no functionality code at start.- Secondly, make it pass by simplyimplementing the missing functionality. Then itturn pass (Green).- Last, refactoring. As we improve the design ofthe code without altering its external behavior,all tests should pass and, thus, we shouldremain green.
  9. 9. Brief summary : TDD- TDD is when you use Automated Testing(usually Unit Testing) as a design practice.- TDD ensures high quality code.- Release work with confident.- Make a collective code ownership since unittest suite is a clear document that everydeveloper in teams can read, follow and writeby individual.
  10. 10. But the defect of TDD- The unit tests still test the behavior of themethod.- It may be difficult to trace the behavior of themethod directly to the behavior that the externalstakeholders asked for and/or understand.- Hence, we consider BDD .
  11. 11. Whats BDD ?- abbreviated from "Behavior DrivenDevelopment".- BDD is an extension/revision of TDD.- BDD specifies that tests of any unit ofsoftware should be specified in terms of thedesired behavior of the unit.
  12. 12. Whats BDD ?- Borrowing from agile software developmentthe "desired behavior" in this case consists ofthe requirements set by the business.- BDD utilizes a "Ubiquitous Language", a bodyof knowledge that can be understood by boththe developer and the customer. Moreover, it isused to shape and develop the requirementsand testing needed, at the level of thecustomers understanding.
  13. 13. How to ?- Popular BDD tools include Cucumber, RSpec,SpecFlow and others.- To explain how to perform simply BDD, wewill illustrate from the Cucumber tool by Rubylanguage .
  14. 14. BDD by Cucumber1: Describe behaviour in plain text
  15. 15. BDD by Cucumber2: Write a step definition in Ruby
  16. 16. BDD by Cucumber3: Run and watch it fail
  17. 17. BDD by Cucumber4: Write code to make the step pass
  18. 18. BDD by Cucumber5: Run again and see the step pass
  19. 19. BDD by Cucumber6: Repeat 2-5 until green like a cuke
  20. 20. Brief summary : BDD- BDD is when you use Automated Testing toflesh out & capture domain logic starting fromthe (high-enough) functional testing down to thedomain unit logic.- BDD ensures high cohesion betweentechnical implementation and the domain.- makes sense to business via the domain unitsand behaviour that domain experts understand.
  21. 21. Summary : Whats differentbetween TDD and BDD ?- BDD focuses on the behavioural aspect of thesystem rather than the implementation aspectof the system that TDD focuses on.- BDD gives a clearer understanding as to whatthe system should do from the perspective ofthe developer and the customer.- TDD only gives the developer anunderstanding of what the system should do.
  22. 22. Summary- One of the principles in agile, "Respondingto change over following a plan". This meansthat do not know in advance what you have tobuild.- TDD and BDD support the change since youcan write exactly needed feature. Also preventoverproduction.
  23. 23. Summary- "Customer collaboration over contractnegotiation". Its clear by using BDD.Customer become to cooperate in softwaredevelopment. Sharpen the product requirementin business aspect.
  24. 24. Reference● Practices of an agile developer: working in the real worldby Venkat Subramaniam, Andy Hunt● Test Driven: Practical TDD and Acceptance TDD for JavaDevelopers by Lasse Koskela● The Cucumber Book: Behaviour-Driven Development forTesters and Developers by Matt Wynne, Matt Wynne●●●●