Developer Testing

Editor's Notes

• #3: 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
• #4: New Development Manager started and he called me into after a particularly bad weekSaid: “Prove to me your code works”
• #5: 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
• #6: 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
• #7: 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
• #8: Focused on making sure that one line of code worksArrange, Act, AssertAlso Business Speak, Given, When, Then (covered later with Acceptance Tests)
• #9: 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!
• #11: Ah Business Value!Meets the customers requirements
• #12: No sense if building the swing on the left if the customer wants the swing on the right
• #14: 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!
• #16: 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
• #17: 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
• #18: Testing is a first class citizenVIP of our code baseWe test as we go firstWe clean up as we goWe are constantly simplifying
• #20: TDD – the thing rightBDD – the right thing
• #22: 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 -
• #23: 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
• #24: *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
• #25: Prove to each other your code works