TEST-DRIVEN AND BEHAVIOR-DRIVEN DEVELOPMENT
•Transferir como PPTX, PDF•
0 gostou•578 visualizações
This document discusses test-driven development (TDD) and behavior-driven development (BDD). It provides insights into TDD, including that TDD is a design technique rather than just a testing technique, and that tests should be written before code and serve as examples of desired behavior as well as a form of communication. BDD extends this idea by specifying requirements in a way that can be tested, such as through Given/When/Then statements. The document advocates an evolutionary approach to design that simplifies code through iterative changes while passing all tests.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a TEST-DRIVEN AND BEHAVIOR-DRIVEN DEVELOPMENT
Semelhante a TEST-DRIVEN AND BEHAVIOR-DRIVEN DEVELOPMENT (20)
Último
Último (20)
TEST-DRIVEN AND BEHAVIOR-DRIVEN DEVELOPMENT
- 1. TEST-DRIVEN DEVELOPMENT BEHAVIOR-DRIVEN DEVELOPMENT Brandon Byars bbyars@thoughtworks.com
- 2. As a software development organization, I want to have more predictability and adaptability So that I can respond to change Given a new requirement When I write the code for it Then I want to know whether I did the right thing
- 3. Analyze Design Code Test Validate
- 4. WHY TDD? Productivity Our goal Immature practices Time
- 5. dS −− dt ≥0 Entropy: It’s the law
- 6. Analyze Design Code Test Validate
- 7. Analyze Design Code Test Validate
- 8. INSIGHT #1: AUTOMATE TEST VERIFICATION Code Analyze Design Validate Test
- 9. [Test] public void ShouldRouteToEchoAction() { var response = new HttpRequest("GET”, "http://localhost/RestMvc/echo/hello" ).GetResponse(); Assert.That(response.StatusCode, Is.EqualTo(200)); Assert.That(response.Body, Is.EqualTo("hello")); }
- 10. INSIGHT #2: TEST FIRST Code Analyze Design Validate Test
- 11. INSIGHT #3: JUST ENOUGH CODE Test Analyze Design Validate Test Code
- 12. [TestFixture] public class StackTest { [Test] public void NewStackShouldBeEmpty() { var stack = new Stack(); Assert.That(stack.IsEmpty()); } }
- 13. public class Stack { public bool IsEmpty() { return false; } }
- 14. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test Design Analyze Validate Test Code
- 15. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test Code Analyze Validate Test Design
- 16. INSIGHT #4: TDD IS A DESIGN TECHNIQUE Test Code Analyze Validate Refactoring Design Test
- 17. TDD is NOT: • A Testing Technique TDD is: • A Design Technique
- 20. “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -Antoine de Saint-Exupery
- 22. EVOLUTIONARY DESIGN Simple Design Rules 1. Must pass all tests 2. Must communicate intent 3. No duplication 4. Use fewest possible (classes, methods…)
- 23. BEHAVIOR DRIVEN DEVELOPMENT There are only two hard problems in computer science: • cache invalidation, and • naming things. -- Phil Karlton
- 24. Test Code Analyze Validate Design Test
- 25. INSIGHT #5: TESTS AS COMMUNICATION Specify Test Code Analyze Validate Design Test
- 26. As a software development organization, I want to have more predictability and adaptability So that I can respond to change Given a new requirement When I write the code for it Then I want to know whether I did the right thing
- 27. private Requirement requirement; [Given(“a new requirement”)] public void GivenANewRequirement() { requirement = new Requirement(); } [When(“I write the code for it”)] public void WhenIWriteTheCodeForIt() { requirement.Satisfy(); } [Then(“I want to know .*”)] public void ThenIWantToKnowIfItWorked() { Assert.That(requirement.IsSatisfied()); }
- 28. WHY NOT TDD? Our goal Productivity We’ll never get here… Time
- 29. TIC TAC TOE https://github.com/bbyars/TicTacToe
Notas do Editor
- Interruptions welcome
- User story (Connectrix –Mike Cohn)How many of you use user stories or acceptance criteria something like this?Generally we recommend writing these *before* you write the code, yes?
- Standard waterfall caricatureA lot happens between us writing that requirement and our ability to validate the code that satisfies itWhat’s the difference b/t test & validate? (doing the thing right vs doing the right thing)
- Top curve (at T0) is a caricature of what I’ve experienced when I delayed testing to the end on a large OMS projectFlat line not really flat – it still trends downwards, but at a much slower and more predictable rateCommon way to stabilize red line – throw armies at it, standardize, add bureacracy, change control = change preventionChaos report – very high rate of failure
- Who knows what this is?Systems tend to disorder over time
- Start by removing the altitude – can give false sense of prestige (design > code > test) that gets in the way of experimentation
- You can do this w/o automation, and in fact those who don’t automate tests actually do thisBut test automation gives you a safety net that scales to catch regression bugs.How many of you are comfortable with test automation?
- Functional test = tests LOTS of code all at onceIf I hadn’t written this, I would have manually tested the same way (through a browser)
- Why would we do that?Helps specify what we want before writing the codeOtherwise we might not write the test (encourages automation)
- Allows you to work in very tiny increments, running tests very frequently
- I wanted to give you an idea of the granularity we’re talking about…
- Yes, really. Kent Beck called this “Fake it until you make it.” Sometimes you just write the code, and in this case maybe I would have.
- Design in the small, percolates to larger design issuesWorks b/c you LISTEN to the tests (too many objects to test something – coupling problem; other object too involved = cohesion problem)Tests automatically give you another user = decreased coupling
- Took me a year to get here…Doesn’t remove need for QAs, although does allow them to focus on higher value workA lot of people want to test private methods when they start TDD.They’re confusing the intent = it’s not about testingWhite box testing is a design smell
- Evolutionary design is an alternative to a lot of heavy up front designNot necessarily mutually exclusiveAllows responding to change well. To take a strained analogy, imagine you were the first person building gloves. You could guess where to make it flexible, or you could just make it the same material throughout, which is a lot simpler. In the latter strategy, the areas that need to be flexible will become flexible over time as we bend our joints. Similarly, in evolutionary design, the parts of the code that need to be flexible become flexible b/c they change a lot, as opposed to trying to build that flexibility in. Sometimes, it can still make sense to build in some flexibility -> we’ve built enough gloves by now that we know where to make them flexible. But not all problems are as well understood as glove making
- A lot of people are uncomfortable with evolutionary design, but I want to emphasize that there’s room for multiple design approaches even on the same project. Classical music relies on a composer carefully crafting a musical piece and directing an orchestra to perform it. Jazz relies on a set pattern of chord transitions and a trust amongst the ensemble to make the most of it.
- TDD followed religiously prevents you from adding anything not needed
- Regardless of design approach, this is true, but in evolutionary design, TDD helps enforce a focus on simplicityEssential vs. accidental complexity
- Enabling change4 = Occam’s razorTension b/t them, esp #2 and #4,which is why priority matters
- * Just sucked in BAs and QAs into the cycle, and by extension, the customerTests serveas documentationSome pursue BDD within the inner circle. Really just a focus on language and business requirements* Emphasize other role involvement
- Note that I started this talk off with a test…
- Tests have a costSpikesStartups?Throw away, one-off codeLearning a language / platform
- Nothing sucks IQ points faster than coding in front of an audience, so if you don’t think I’m an imbecile yet, wait a few minutes…