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
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 TestingCode Quality and You
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!
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…
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?
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
Acceptance Tests• A user story is not considered complete untilthe acceptance tests have passed
UI & Manual Tests• Harder to automate• Still need to do exploratory testing
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
Composition of the Tests• Happy Paths• Sad Paths• “Woah, wasn’t expecting that” Paths
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
Test Driven Development (TDD)• Write a Test that fails• Write some code• Make all Tests pass• Refactor• Rinse and Repeat
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
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
What about Code Reviews?• Absolutely!• But the first question needs to be “show methe passing tests”• Make sure we are getting better at writingtests
The Who• Quality is everyone’s responsibility– Devs– QAs– BAs– UX– Product Owners
The When• During each sprint:– BA, Dev & QA all collaborating and following eachstory to completion• Today!
Developer Testing• “How do I sell my executive team on doing thisstuff? Dont. Just do it. They dont know whatyoure doing anyway” —Jim Highsmith