Developer Testing

313 views

Published on

Slides from a Lunchtime Tech-talk, I did regarding Unit, Integration, and Acceptance Testing
TDD, BDD

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
313
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Developer Testing

    1. 1. Developer TestingCode Quality and You
    2. 2. If it builds, ship it• Was young and foolish• Talk to a BA? QA? Never!• Just focused on writing code – not on qualitycode• Bugs and bugs, oh my!
    3. 3. In all fairness• Was young and naïve• “It worked on my machine”• Still a start-up with a start-up mentality wherethe “Wild west” was accepted• But still there had to be a better way…
    4. 4. Ta-da!
    5. 5. Unit Tests• Focuses on the smallesttestable part of anapplication• Independent
    6. 6. Unit Testing• Cheap!• Finds problems early• Facilitates changes• Promotes decoupling• Living Documentation
    7. 7. Example Unit Test
    8. 8. Integration Tests• Verifies functional, performance, andreliability– Do all the individual “units” work together?– Do all the combined “units” work in a performantmanner?– Do all the “units” work with external resourcesand/or dependencies?
    9. 9. Integration Test Example
    10. 10. Acceptance Tests• Higher-level tests that verify completeness ofa 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. 11. Acceptance Tests• A user story is not considered complete untilthe acceptance tests have passed
    12. 12. Acceptance Test Example
    13. 13. UI & Manual Tests• Harder to automate• Still need to do exploratory testing
    14. 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 createdpreviously with concurrency and load against abenchmark
    15. 15. Composition of the Tests• Happy Paths• Sad Paths• “Woah, wasn’t expecting that” Paths
    16. 16. Testing Anti-Patterns• But aren’t code reviews a substitute?• But we are near the end of Project XYZ; whyshould we add tests now?• But couldn’t we “break” the code by addingtests?• But it will take a longer time to complete• But our code-base is too large/complex to addtests
    17. 17. Test Driven Development (TDD)• Write a Test that fails• Write some code• Make all Tests pass• Refactor• Rinse and Repeat
    18. 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. 19. TDD v BDD• If I am doing BDD then do I need to do TDD orvice versa?– Absolutely!– TDD makes sure you are writing the thing right;BDD makes sure you are writing the right thing
    20. 20. What about Code Reviews?• Absolutely!• But the first question needs to be “show methe passing tests”• Make sure we are getting better at writingtests
    21. 21. The Who• Quality is everyone’s responsibility– Devs– QAs– BAs– UX– Product Owners
    22. 22. The When• During each sprint:– BA, Dev & QA all collaborating and following eachstory to completion• Today!
    23. 23. Developer Testing• “How do I sell my executive team on doing thisstuff? Dont. Just do it. They dont know whatyoure doing anyway” —Jim Highsmith

    ×