Developer Testing
•Descargar como PPTX, PDF•
0 recomendaciones•343 vistas
Slides from a Lunchtime Tech-talk, I did regarding Unit, Integration, and Acceptance Testing TDD, BDD
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Developer Testing
Similar a Developer Testing (20)
Último
Último (20)
Developer Testing
- 1. Developer Testing Code Quality and You
- 2. If it builds, ship it • Was young and foolish • Talk to a BA? QA? Never! • Just focused on writing code – not on quality code • Bugs and bugs, oh my!
- 3. In all fairness • Was young and naïve • “It worked on my machine” • Still a start-up with a start-up mentality where the “Wild west” was accepted • But still there had to be a better way…
- 4. Ta-da!
- 5. Unit Tests • Focuses on the smallest testable part of an application • Independent
- 6. Unit Testing • Cheap! • Finds problems early • Facilitates changes • Promotes decoupling • Living Documentation
- 8. Integration Tests • Verifies functional, performance, and reliability – Do all the individual “units” work together? – Do all the combined “units” work in a performant manner? – Do all the “units” work with external resources and/or dependencies?
- 10. Acceptance Tests • Higher-level tests that verify completeness of a user story • Written in Gherkin: Given that I’m Product Owner, When the sprint ends, Then all of the stories should meet my requirements • Highly collaborative between customers, Product Owners, BAs, QAs and Devs
- 11. Acceptance Tests • A user story is not considered complete until the acceptance tests have passed
- 13. UI & Manual Tests • Harder to automate • Still need to do exploratory testing
- 14. But what about… • Regression Testing? – Rerun all of the tests we created previously • Smoke Testing? – Rerun a subset of the tests we created previously • Performance Testing? – Rerun a focused subset of the tests we created previously with concurrency and load against a benchmark
- 15. Composition of the Tests • Happy Paths • Sad Paths • “Woah, wasn’t expecting that” Paths
- 16. Testing Anti-Patterns • But aren’t code reviews a substitute? • But we are near the end of Project XYZ; why should we add tests now? • But couldn’t we “break” the code by adding tests? • But it will take a longer time to complete • But our code-base is too large/complex to add tests
- 17. Test Driven Development (TDD) • Write a Test that fails • Write some code • Make all Tests pass • Refactor • Rinse and Repeat
- 18. Behaviour Driven Development (BDD) • Write a Test* that fails • Write some code • Make all Tests pass • Refactor • Rinse and Repeat *With a different purpose in mind; acceptance
- 19. TDD v BDD • If I am doing BDD then do I need to do TDD or vice versa? – Absolutely! – TDD makes sure you are writing the thing right; BDD makes sure you are writing the right thing
- 20. What about Code Reviews? • Absolutely! • But the first question needs to be “show me the passing tests” • Make sure we are getting better at writing tests
- 21. The Who • Quality is everyone’s responsibility – Devs – QAs – BAs – UX – Product Owners
- 22. The When • During each sprint: – BA, Dev & QA all collaborating and following each story to completion • Today!
- 23. Developer Testing • “How do I sell my executive team on doing this stuff? Don't. Just do it. They don't know what you're doing anyway” —Jim Highsmith
Notas del editor
- First job out of University:Consolidated tracking across 100+ websites in classic aspWanted to prove myselfLots of different websites worked differently; meant my framework needed to backwards compatible and cater for 15 ways of doing the same thingEnded up introducing a lot of bugs
- New Development Manager started and he called me into after a particularly bad weekSaid: “Prove to me your code works”
- He introduced me to Unit and Integration testsAcceptance and UI picked up laterCost of Execution/Cost of MaintenanceExecution Time also takes longer at each layerAs we get lower the closer into the code we getTherefore we can automate more and moreThus we want to place most of the effort the lower we can
- SMALLEST partSmaller than a method1 line of code; 1 statementIndependent of the rest of the systemIndependent of the databaseIndependent of any other testRather than praying the code works
- Cheap to create, cheap to maintain, cheap to runDoes it build, earliest we can catch issuesDo all these test pass – second earliest (no waiting for deployment, QA, etc)Can lean on the testsFear of breaking changes goes awayNew startersSeparation of concernsSimplifies codeRemoved “magic”Tell us what the system doesDon’t have to “dig into the code”Writing them in business language
- Focused on making sure that one line of code worksArrange, Act, AssertAlso Business Speak, Given, When, Then (covered later with Acceptance Tests)
- Once we start putting each part together does the system still work?Once we start putting each part together does it all perform as we would expect Can we catch issues lower than Page XYZ is “slow”Can we access the database, a schema change hasn’t broken the codeBuilds upon Unit Tests:Still relatively cheap – may need an environment to execute inShould still be independent!
- Ah Business Value!Meets the customers requirements
- No sense if building the swing on the left if the customer wants the swing on the right
- Yvette’s Fashion and Costume shop – meets all the acceptances tests and works bug free; however…Exploratory testing to discover new scenarios and test casesBut once repeatable lets automate it!
- Happy Kenau - The scenarios we want to happen; the expected behaviour of the system - Positive casesSad Kenau - The scenarios where it won’t work - Negative casesWoahKenau - Extreme edge cases, ie Database connection dies, out of disk space, etc
- Code Reviews: No, they are still manual and therefore inherently unrepeatable Can they catch every possible scenario?End of Project: Is it the end of the application’s lifecycle? How much longer will we need to support it? If we have to do any change, we need testsBreak by Adding tests Absolutely; however, we can write a test for that! Couldn’t you break the code by adding new code anyway?Longer to complete Does it really take longer? Imagine if you didn’t have to go back and fix any bugs or have QA fail a user story and you have to figure out why There is an upfront cost; however, quality will always make you pay – and that can be pay me now or pay me later (and later is always more costly) Similar to we have to deliver by date x Then this is all the more reason not an excuse to throw them outLarge/Complex If it is too large/complex to test then it is too large/complex to add any kind of change We need to simplify and testing helps us achieve that
- Testing is a first class citizenVIP of our code baseWe test as we go firstWe clean up as we goWe are constantly simplifying
- TDD – the thing rightBDD – the right thing
- Devs - You are the closes to the code and the ones making the changes - Measure twice before cuttingQAs - You are our ultimately quality gatekeepers; ensuring that the functionally produced meets the requirementsBAs - Get in there, help write acceptance tests for Devs and QAs to work fromUX - Test frameworks for javascript - UI from the beginningProduct Owners - need to understand that delivery on scope and on time sacrifices quality - delivering quality on time while sacrificing scope is always betterEveryone else -
- During each sprint, let’s collaborate for each story. As the BA is flushing out the acceptance criteria the Dev is writing the unit, integration tests and ultimately the code for it and the QA is writing the acceptance test for it.Let’s stop catapulting over the walls!A lot of these practises we can start today! They aren’t technology dependent.Any new development initiatives/projects, lets start incorporating these methods.Any existing let’s start looking at how we can make them testableThose using .net, your lives will be easierThose not, there is hope
- *They expect you are doing anywayAny code in your project – regardless if you wrote it – is YOUR codeYour career - Check Job BoardsDo your own researchRead from our Library:The Pragmatic ProgrammerClean CodeTest Driven DevelopmentTrainingWhat else?Try it; what doyou have to lose?Understand and embrace that proving the code quality is beneficial to everyone
- Prove to each other your code works