Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
John Ferguson Smart Limited, profile picture
Uploaded byJohn Ferguson Smart Limited
PDF, PPTX4,458 views

Real Developers Don't Need Unit Tests

The document discusses the myth that real developers don't need unit tests and uses Chuck Norris as a humorous example to debunk this notion. It also explains Test-Driven Development (TDD) as a design strategy that promotes writing better code through a structured process of writing tests before code. The document emphasizes the importance of TDD in improving code quality and maintaining confidence in software changes.

Technology◦
Download as PDF, PPTX
Real Developers Don’t Need Unit Tests Mythbusting TDD myths John Ferguson Smart Wakaleo Consulting Ltd. http://www.wakaleo.com Email: john.smart@wakaleo.com Twitter: wakaleo
Introduction Real Developers Don’t Need Unit Tests
Introduction Real Developers Don’t Need Unit Tests Bugs?
Introduction Real Developers Don’t Need Unit Tests Bugs? Chuck Norris’s code doesn’t have bugs
Introduction Real Developers Don’t Need Unit Tests Bugs? Chuck Norris’s code doesn’t have bugs His code always work. ALWAYS.
Introduction Real Developers Don’t Need Unit Tests Bugs?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Chuck Norris’s code is perfectly designed the first time round
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Chuck Norris’s code is perfectly designed the first time round His favorite design pattern is the Roundhouse Kick
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Chuck Norris doesn’t need technical documentation
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Chuck Norris doesn’t need technical documentation He just stares down the code until it tells him everything he wants to know
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements? Chuck Norris doesn’t need requirements to be executable
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements? Chuck Norris doesn’t need requirements to be executable He can execute whatever he wants
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements? Acceptance Tests?
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements? Acceptance Tests? Chuck Norris doesn’t need acceptance tests
Introduction Real Developers Don’t Need Unit Tests Bugs? Emergent design? Technical documentation? Executable requirements? Acceptance Tests? Chuck Norris doesn’t need acceptance tests No one refuses to accept Chuck
Introduction Real Developers Don’t Need Unit Tests
Introduction Real Developers Don’t Need Unit Tests OK, so Chuck Norris doesn’t need Unit Tests
Introduction Real Developers Don’t Need Unit Tests OK, so Chuck Norris doesn’t need Unit Tests But what about the rest of us?
TDD Basics
TDD Basics So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code Have more confidence in our code So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code Have more confidence in our code Make changes more easily So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code Have more confidence in our code Make changes more easily Write code that meets user requirements more accurately So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code Have more confidence in our code Make changes more easily Write code that meets user requirements more accurately (and incidentally...) So what is this TDD thing, anyway?
TDD Basics TDD is not about writing tests TDD is a design strategy: Write better-designed code Have more confidence in our code Make changes more easily Write code that meets user requirements more accurately (and incidentally...) Build up a comprehensive set of automated tests So what is this TDD thing, anyway?
TDD Basics The TDD development process “Never write a single line of code unless you have a failing automated test. Eliminate duplication.” - Kent Beck
TDD Basics The TDD development process “Never write a single line of code unless you have a failing automated test. Eliminate duplication.” - Kent Beck TEST Write a failing unit test. Ensure that it fails.
TDD Basics The TDD development process “Never write a single line of code unless you have a failing automated test. Eliminate duplication.” - Kent Beck TEST Write a failing unit test. Ensure that it fails. CODE Write production code to make the test pass.
TDD Basics The TDD development process “Never write a single line of code unless you have a failing automated test. Eliminate duplication.” - Kent Beck TEST Write a failing unit test. Ensure that it fails. CODE Write production code to make the test pass. REFACTOR Tidy up the design
TDD Basics TEST CODE REFACTOR
TDD Basics Step 1) Write a test TEST CODE REFACTOR
TDD Basics Step 1) Write a test TEST Design your code from the outside-in CODE REFACTOR
TDD Basics Step 1) Write a test TEST Design your code from the outside-in How will your code be used? CODE REFACTOR
TDD Basics Step 1) Write a test TEST Design your code from the outside-in How will your code be used? CODE Design a clean interface for your code REFACTOR
TDD Basics Step 1) Write a test TEST Design your code from the outside-in How will your code be used? CODE Design a clean interface for your code Implement only features that are really needed REFACTOR
TDD Basics Step 1) Write a test TEST Design your code from the outside-in How will your code be used? CODE Design a clean interface for your code Implement only features that are really needed REFACTOR Provide examples of how you expect your code to be used
TDD Basics Step 1) Write a test TEST Design your code from the outside-in How will your code be used? CODE Design a clean interface for your code Implement only features that are really needed REFACTOR Provide examples of how you expect your code to be used How will my code be used by the rest of the application? ?
TDD Basics TEST CODE REFACTOR
TDD Basics Step 2) Write some code TEST CODE REFACTOR
TDD Basics Step 2) Write some code TEST Just enough code to make the tests pass CODE REFACTOR
TDD Basics Step 2) Write some code TEST Just enough code to make the tests pass Might mean a non-optimal solution at this stage... CODE REFACTOR
TDD Basics Step 2) Write some code TEST Just enough code to make the tests pass Might mean a non-optimal solution at this stage... CODE REFACTOR Just make it pass the test...
TDD Basics TEST CODE REFACTOR
TDD Basics TEST CODE REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST CODE REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST Evolutionary (emerging) design CODE REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST Evolutionary (emerging) design Keep the code clean! CODE REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST Evolutionary (emerging) design Keep the code clean! CODE Remove duplication and fix design problems REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST Evolutionary (emerging) design Keep the code clean! CODE Remove duplication and fix design problems Restructure existing code - no new features! REFACTOR It works. Now let’s tidy things up.
TDD Basics Step 3) Tidy up TEST Evolutionary (emerging) design Keep the code clean! CODE Remove duplication and fix design problems Restructure existing code - no new features! REFACTOR Make sure the tests still pass! It works. Now let’s tidy things up.
TDD in Action - the Game Of Life
TDD in Action - the Game Of Life So where do we start?
TDD in Action - the Game Of Life So where do we start? Let’s list some requirements
TDD in Action - the Game Of Life So where do we start? Let’s list some requirements The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live cells with 2 or 3 live neighbours remain alive - Dead cells with 3 neighbours become alive
TDD in Action The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action Now what? The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action Now what? So what do we mean by this first requirement? The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action So what do we have to code for this one. The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action So what do we have to code for this one. Dunno yet. Let’s write some acceptance tests to find out The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live User Story 1or Less than 2 neighbours die cells with 2 - 3 live neighbours remain alive - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive When the next generation is created Then this cell will die
TDD in Action So what do we have to code for this one. Dunno yet. Let’s write some acceptance tests to find out The Game of Life - Live cells with less than 2 live neighbours die - Live cells with more than 3 live neighbours die - Live UserUser StoryLessAcceptance criteria die cells Story 1or 3 live neighbours remain alive with 2 - 1 - than 2 neighbours - Dead cells cell with less than 2 live neighbours Given a with 3 neighbours become alive Sample grid transitions: 1) 2) When the next generation is created Then this cell will die
TDD in Action
TDD in Action Great, so now I can start coding, right?
TDD in Action Great, so now I can start coding, right? Not so fast, hot shot. We need to turn this into an ‘executable requirement’
TDD in Action Great, so now I can start coding, right? Not so fast, hot shot. We need to turn this into an ‘executable requirement’ public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { } }
TDD in Action public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { } }
TDD in Action I still don’t know what to write in this test... public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { } }
TDD in Action I still don’t know what to write in this test... Start by expressing what you are trying to achieve public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { } }
TDD in Action I still don’t know what to write in this test... Start by expressing what you are trying to achieve public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; String nextGrid = null; assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; String nextGrid = null; assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action But that test will fail! What now? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; String nextGrid = null; assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action But that test will fail! What now? How you would like the code to look, if you had to use it? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; String nextGrid = null; assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action But that test will fail! What now? How you would like the code to look, if you had to use it? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what’s so special about this test? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what’s so special about this test? The test name describes the expected behaviour public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what’s so special about this test? The test name describes the expected behaviour public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } } We started by expressing our expectations
TDD in Action So what’s so special about this test? The test name describes the expected behaviour public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + The code is written for API "...n" + users, not API developers "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } } We started by expressing our expectations
TDD in Action So what’s so special about this test? The test name describes the expected behaviour public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; It’s a working String expectedNextGrid = "...n" + The code is written for API example of how "...n" + users, not API developers to use the class "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } } We started by expressing our expectations
TDD in Action public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what now? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what now? This is our acceptance test. Now we drill down. public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So what now? This is our acceptance test. Now we drill down. public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So I guess you’ll say we need to write a test? public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So I guess you’ll say we need to write a test? Spot on! You catch on fast! public class GameOfLifeTest { @Test public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { String initialGrid = "...n" + "...n" + "..."; String expectedNextGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action So I guess you’ll say we need to write a test? Spot on! You catch on fast! public class UniverseTest { @Test public class GameOfLifeTest { public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() { @Test String seededGrid = "...n" + public void aCellWithNoNeighboursShouldDieInTheNextGeneration() { "...n" + String initialGrid = "...n" + "..."; "...n" + "..."; Universe theUniverse = new Universe(seededWith(seededGrid)); String currentGrid = theUniverse.getGrid(); String expectedNextGrid = "...n" + assertThat(currentGrid, is(seededGrid)); "...n" + } "..."; } Universe theUniverse = new Universe(seededWith(initialGrid)); theUniverse.createNextGeneration(); String nextGrid = theUniverse.getGrid(); assertThat(nextGrid, is(expectedNextGrid)); } }
TDD in Action public class UniverseTest { @Test public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() { String seededGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(seededGrid)); String currentGrid = theUniverse.getGrid(); assertThat(currentGrid, is(seededGrid)); } }
TDD in Action So now can we code? public class UniverseTest { @Test public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() { String seededGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(seededGrid)); String currentGrid = theUniverse.getGrid(); assertThat(currentGrid, is(seededGrid)); } }
TDD in Action So now can we code? Yes, but just a little bit public class UniverseTest { @Test public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() { String seededGrid = "...n" + "...n" + "..."; Universe theUniverse = new Universe(seededWith(seededGrid)); String currentGrid = theUniverse.getGrid(); assertThat(currentGrid, is(seededGrid)); } }
TDD in Action So now can we code? Yes, but just a little bit public class UniverseTest { @Test public class Universe { public void aUniverseSeededWithAnEmpyGridContentWillContainAnEmptyGrid() { public Universe(String initialGridContents) {} String seededGrid = "...n" + public static String seededWith(String gridContents) { "...n" + return null; "..."; } Universe theUniverse = new Universe(seededWith(seededGrid)); public void createNextGeneration() {} String currentGrid = theUniverse.getGrid(); assertThat(currentGrid, is(seededGrid)); } public String getGrid() { } return "...n" + "...n" + "..."; } }