Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Download as PPTX, PDF•0 likes•281 views
The document discusses the fallacies of Test-Driven Development (TDD) and highlights misconceptions such as developers writing unit tests that don’t fit the formal definition, and acceptance tests being ineffective due to lack of customer participation. It emphasizes the importance of behavior-driven development and the need for clear requirements for writing effective tests. The author critiques the common belief that TDD guarantees 100% test coverage and argues for a more thoughtful approach to testing and code design.
![Need-driven Development [is a] variation on the test-driven
development process where code is written from the outside in
and all depended-on code is replaced by Mock Objects that verify
the expected indirect outputs of the code being written.
Meszaros, Gerard. xUnit Test Patterns](https://image.slidesharecdn.com/kentbeckstyletdd-sevenyearsafter-201013092644/85/Ian-Cooper-webinar-for-DDD-Iran-Kent-beck-style-tdd-seven-years-after-11-320.jpg)
![Originally called Functional Tests because each acceptance
test tries to test the functionality of a user story.
Acceptance tests are different [is] modeled and possibly
even written by the customer. ...Hence the even-newer
name, Customer Test.
https://wiki.c2.com/?AcceptanceTest](https://image.slidesharecdn.com/kentbeckstyletdd-sevenyearsafter-201013092644/85/Ian-Cooper-webinar-for-DDD-Iran-Kent-beck-style-tdd-seven-years-after-23-320.jpg)
![Customers illustrate their descriptions with concrete
examples…programmers use these examples to guide their
work…Sometimes [programmers] use the examples directly in their
tests…More often…programmers use the examples as a guide,
writing a multitude of more focused, programmer-centric tests as
they use TDD
https://www.jamesshore.com/v2/blog/2010/alternatives-to-acceptance-testing](https://image.slidesharecdn.com/kentbeckstyletdd-sevenyearsafter-201013092644/85/Ian-Cooper-webinar-for-DDD-Iran-Kent-beck-style-tdd-seven-years-after-25-320.jpg)
![The Refactoring Step is when we produce clean code.
It’s when you apply patterns [Kerievsky].
It’s when you remove duplication [Beck]
It’s when you sanitize the code smells. [Fowler]](https://image.slidesharecdn.com/kentbeckstyletdd-sevenyearsafter-201013092644/85/Ian-Cooper-webinar-for-DDD-Iran-Kent-beck-style-tdd-seven-years-after-55-320.jpg)
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
- 1. TDD, where did it all go wrong? Seven years after
- 2. Who are you? • Software Developer for more than 20 years • Worked mainly for ISVs • Reuters, SunGard, Misys, Huddle • Worked for a couple of MIS departments • DTI, Beazley • Microsoft MVP for C# • Interested in architecture and design • Interested in Agile methodologies and practices • No smart guys • Just the guys in this room 2
- 3. 3
- 4. Agenda • The Fallacies of TDD • Red-Green-Refactor • Behavior not Details • Clean Architecture • Principles 4
- 5. 2013
- 7. The Fallacies of TDD
- 8. 1: Developers write Unit Tests
- 9. I call them “unit tests,” but they don't match the accepted definition of unit tests very well Kent Beck, TDD By Example
- 10. To isolate issues that may arise, each test case should be tested independently. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation. https://en.wikipedia.org/wiki/Unit_testing
- 11. Need-driven Development [is a] variation on the test-driven development process where code is written from the outside in and all depended-on code is replaced by Mock Objects that verify the expected indirect outputs of the code being written. Meszaros, Gerard. xUnit Test Patterns
- 12. Our need for Inversion of Control containers, over Poor Man’s DI is due to Need-Driven Development
- 13. When I look around now, I see a lot of people using mocks to replace all their dependencies. My concern is that they will begin to hit the Fragile Test issues that mocks present. Gerard Meszaros identifies the issues we hit as two specific smells: Overspecified Software and Behavior Sensitivity. http://codebetter.com/iancooper/2007/12/19/mocks-and-the-dangers-of-overspecified-software/
- 15. Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. https://martinfowler.com/bliki/DefinitionOfRefactoring.html
- 16. If the program’s behavior is stable from an observer’s perspective, no tests should change. https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934
- 17. My personal style is I just don’t go very far down the mock path… your test is completely coupled to the implementation not the interface… of course you can’t change anything without breaking the tests Kent Beck https://www.youtube.com/watch?v=z9quxZsLcfo
- 18. Failure of a Unit Test shall implicate one (1) and only one (1) unit. (A method, class, module, or package.) Failure of a Programmer Test, under Test Driven Development, implicates only the most recent edit. https://wiki.c2.com/?ProgrammerTest https://wiki.c2.com/?DeveloperTest
- 19. Test Driven Development produces Developer Tests. The failure of a test case implicates only the developer's most recent edit. This implies that developers don't need to use Mock Objects to split all their code up into testable units. And it implies a developer may always avoid debugging by reverting that last edit. https://wiki.c2.com/?UnitTest
- 20. How should the running of tests affect one another? Not at all. Kent Beck, TDD By Example
- 21. Avoid using mocks for anything other than issues with: • Isolated Test • Fast Test • Fragile Test
- 22. 2: Customers write Acceptance Tests
- 23. Originally called Functional Tests because each acceptance test tries to test the functionality of a user story. Acceptance tests are different [is] modeled and possibly even written by the customer. ...Hence the even-newer name, Customer Test. https://wiki.c2.com/?AcceptanceTest
- 24. These two problems--that customers don't participate, which eliminates the purpose of acceptance testing, and that they create a significant maintenance burden, means that acceptance testing isn't worth the cost. I no longer use it or recommend it. James Shore, http://www.jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html
- 25. Customers illustrate their descriptions with concrete examples…programmers use these examples to guide their work…Sometimes [programmers] use the examples directly in their tests…More often…programmers use the examples as a guide, writing a multitude of more focused, programmer-centric tests as they use TDD https://www.jamesshore.com/v2/blog/2010/alternatives-to-acceptance-testing
- 26. TDD should create tests that can be read, so that others can understand the requirements
- 27. ATDD is perilous because it implies that TDD does not deal with the acceptance criteria for stories
- 28. 3: The trigger for a new test is a new function
- 29. The trigger for a test is a new requirement
- 30. We need to be able to add amounts in two different currencies and convert the result given a set of exchange rates. Kent Beck, TDD By Example
- 31. The next test you write in TDD is just the most obvious step that you can make towards implementing the requirement given by a use case or user story.
- 32. I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour- driven development. https://dannorth.net/introducing-bdd/
- 33. 4: It doesn’t matter if you are test first or test last
- 34. You need a way to think about design, you need a method for scope control Kent Beck, TDD By Example
- 35. When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Kent Beck, TDD By Example
- 36. If you are struggling to write a test, because the acceptance criteria for the story are not clear – TDD is working
- 37. One of the hardest things to communicate about test-driven development is the mental state that it puts you in. Martin Fowler in Kent Beck, TDD By Example
- 38. 5: You want 100% test coverage of your code
- 39. If we test first, we don’t end up with speculative code.
- 40. We should not introduce new paths in refactoring, we need a new test.
- 41. But not all of our code should be driven by TDD
- 42. Don’t drive visual output Don’t drive a spike or other throwaway code Don’t drive 3rd party code Don’t drive integration
- 43. TDD is for fast binary feedback. It works best where we can develop in short cycles. If the feedback is not quick, consider another method to confirm This is where we use a test double
- 44. 6: TDD is sufficient
- 48. 1: Developers write Unit Tests 2: Customers write Acceptance Tests 3: The trigger for a new test is a new function 4: It doesn’t matter if you are test first or test last 5: You want 100% test coverage of your code 6: TDD is sufficient
- 50. Red-Green-Refactor 1 Red Write a little test that doesn't work, and perhaps doesn't even compile at first. 2.Green Make the test work quickly, committing whatever sins necessary in the process. 3.Refactor Eliminate all of the duplication created in merely getting the test to work.
- 51. Write a test. Remove duplication. Make it compile. Run it to see that it fails. Make it run.
- 52. Make it run. Quickly getting that bar to go to green dominates everything else. This shift in aesthetics is hard for some experienced software engineers. This is not just about accepting sin, its about being sinful Write sinful code!
- 53. We can commit any number of sins to get there, because speed trumps design, just for that brief moment. Kent Beck, TDD by Example
- 54. Good design at good times. Make it run, make it right. Kent Beck, TDD by Example
- 55. The Refactoring Step is when we produce clean code. It’s when you apply patterns [Kerievsky]. It’s when you remove duplication [Beck] It’s when you sanitize the code smells. [Fowler]
- 56. Pattern Test Writing Refactoring Command X Value Object X Null Object X Template Method X Pluggable Object X Pluggable Selector X Factory Method X X Imposter X X Composite X X Collecting Parameter X X Kent Beck, TDD By Example
- 57. You do not write new unit tests when refactoring to clean code. You are not introducing public classes. It is likely if you feel the need to introduce a new public class, you may need collaborators that fulfill a role.
- 60. Delivery Mechanism Request Model Response Model Interactor <<interface>> Entity Entity Entity Entity Data Structure Frameworks & Drivers Boundary Interface Adapters Use Cases Entity Gateway <<interface>> 60
- 61. We write tests against use cases Our tests are just another adapter
- 62. XUnit Framework Request Model Response Model Interactor <<interface>> Entity Entity Entity Entity Data Structure Frameworks & Drivers Test Interface Adapters Use Cases Entity Gateway <<interface>> In-Memory DB Delivery Mechanism 62
- 63. XUnit Framework Request Model Response Model IHandleRequests <<interface>> Entity Entity Entity Entity Data Structure Frameworks & Drivers Test Interface Adapters Use Cases Entity Gateway <<interface>> In-Memory DB Delivery Mechanism 63 AsyncRequest Handler
- 64. We don’t write tests against the adapterOur tests are just another adapter
- 65. We write system tests for acceptance
- 66. Principles
- 67. 1:Respond to behaviour changes 2: Not respond to structure changes 3: Should be Fast 4: Should not be fragile 5: Cheap to write 6: Easy to read 7: Easy to change https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934
- 68. Q&A