XP through TDD

eXtreme Programming Introduction TELEFÓNICA I+D Date: © 2010 Telefónica Investigación y Desarrollo, S.A. Unipersonal With Test-Driven Development Jacob Cañadas <jcr@tid.es> Marc Planagumà <mpv@tid.es> Mauricio Cappella <mauricio@pollenizer.com>

01 XP with TDD 02 TDD = Test + driven development 03 V-model for testing 04 Driven Development, why? 05 Steer your project with tests (V-model for TDD) 06 TDD is easy and optimal 07 TDD is the easier way to implement XP and Agile 08 Examples 09 Questions Part 1: overview (1h)

01 Reference architecture. 02 Web frontend and integration of 3rd party services. 03 Mobile applications and services. 04 Provisioning framework. 05 (your example or question here) Part 2: examples (1h)

eXtrem Programing Practices: TDD is core 01

eXtrem Programing Practices: TDD is core 01 TDD

Test-Driven Development is: Test Drive Development 02

Ex: Control access to building Check user credentials, if ok store date

func storeUserAccess(userId,accessDate) : mysql.query(“insert into user (id,date) values(userId,accessDate)”) func readUserAccess() : userId,accessDate=openPcd.getLastAccess() return userId,accessDate

func accessControlSystem() : userId,accessDate = readUserAccess() if(userAllowed(userId)) print( userId enter building on accessDate) storeUserAccess(userId,accessDate) return true else print( userId can’t enter) return false

Uni Test Method level Test boundaries values Test extreme values Without dependences If (x>=2) return(x) else return(2x)

func storeUserAccess(userId,accessDate) : mysql.query(“insert into user (id,date) values(userId,accessDate)”) func storeUserAccessTest() : storeUserAccess(‘user123’,’06/04/2010’) accessDate = readLastUserAccess(‘user123’) assertTrue (accessDate = ‘06/04/2010‘)

func storeUserAccessMock(userId,accessDate) : //Nothing to do func readUserAccessMock() : if(firstTime) return ‘userOk’,’06/04/2010’ else return ‘userKo’,’06/04/2010’

func accessControlSystem() : userId,accessDate = readUserAccessMock() if(userAllowed(userId)) print( userId enter building on accessDate) storeUserAccessMock(userId,accessDate) return true else print( userId can’t enter) return false

func accessControlSystemTest() : result =accessControlSystem() AssertTrue(result) result =accessControlSystem() AssertFalse(result)

func accessControlSystemTestIt() : result =accessControlSystem() AssertTrue(result) result =accessControlSystem() AssertFalse(result)

Driven Development: where should we go? 04

1. Describe intent with tests. 2. Use the tests to validate our solution iteratively 3. Do the simplest thing that could possibly work.

Clear user stories and backlog Contract Check the acceptance criteria Doc Based Script Based User interaction

Simple design and constant review about: Tecnologines Architecture Ensure you are using the right tools. Deployment Connectivity Performance and SLA

Correct orchestration : Interchangeable components. Code simultaneously. Moularization. Define good components contracts and interfaces. Protocol Interfaces API’s

Get better Code: Atomic functions No bugs Simple code Test is documnetation. Clear goals minimum effort: Paremeters pre & post conditions

TDD is easy and optimal. 06 Create Time Create Team Create effectiveness

TDD is easy and optimal. Use tests to: Define and mockup integration interfaces. Make clear how your app works. Show how your components or libraries may be used Document what do you expect from 3rd party tools, libraries and services and check compatibility Evaluate implementation alternatives Demo your user stories Refactor your code without breaking something 06

TDD is easy, and optimal replaces more expensive practices Do you write a "main" to try a function? make it readable, keep it, and it's TDD (and your documentation too!) Tests are better than Word documents and UML and flow charts: just can run them to know if they are accurate they change with your code and are where you need them. Avoid being blocked by integration problems. Save expensive bug finding. Reduce risks due to long build and release cycles. 06

TDD, the easier way to XP and Agile Acceptance criteria : Clear user stories and backlog. Customer tests. Acceptance test : do exactly what the customer asks, no less, no more (the simplest thing that may possibly work) Continuous testing: bug free, easy to deploy (CI) Everybody runs and tests everything: Whole team, Collective Ownership and Coding Standard. TDD makes each developer also an architect and clearly documents her reasoning and decisions: Simple design (KISS) Refactor Without TDD = disaster 07

Example User Story 08 As a: Mobile phone user I want to: receive a list of 3 places to eat at less than 30min from where me and the contacts I select are So that: I can propose my contacts to meet there

Use Acceptance Tests to validate UserStory 08 Test 0: create wireframes showing the sequence of screens the user views and validate them with the PO and user Test 0.1: is feasible? write tests to check you can always get the information to generate the right screens in each scenario allContacts= phoneDriver.getContacts() selectedContacts= ui.selectFromList(allContacts) result= nearUsApp.find(selectedContacts,"placeToEat",30m) if result.length<1 { showMsg("ERROR: no places found") } else { m= new List(); foreach place in result { m.add(place.desc); foreach path in place.contactPath { m.add(" >"+path.contact+": "+path.transport) }} ui.showList(m) } (most of the mentioned application classes and methods have to be written yet!) BUT now you now exactly what the PO wants and you need!

Use Acceptance Test to drive Behavior (more on how to do this in your projects in part 2) 08 Test 0.2: implement what you need as stubs and pass the tests for all thinkable scenarios (you wrote the top layer of your app as) ... result= nearUsApp.find(selectedContacts,"placeToEat",30m) if result.length<1 { showMsg("ERROR: no places found") } else { ... ui.showList(m) } (now you can use mock objects like) ... phoneDriver.getContacts(){ return ["Juan35m","Pedro20m"]} ui.selectFromList(l) { return l[0] } nearUsApp.find(contacts, kindOfPlace, timeToGetThereMax) { if (contacts[0]=="Juan35m") { return [] } return [...3 lugares...] //you must try none, 3 near, etc. } And TEST that running the application code you already wrote with different inputs (selecting different contacts) gives the expected results (no places to meet Juan35m in less tha 30min, etc.)

Use System Tests to drive Architecture (more on how to do this in your projects in part 2) 08 How do you get all the information the past tests show you need? How do you transport it from one place to another? Are the tools you intend to use available in the all target environments? How reliable are this tools? How fast? Can you accommodate more than one alternative? Test: write tests connecting to all the needed data sources and services, check your app understands all the results and errors Test: deploy simple stress test applications using each of the tools you may use to the target environments Test: stress test the architecture implement all the communications and data handling required by the components, using stubs only to simulate errors and ensuring you return data for all the relevant scenarios So: the team is sure the tools work, the application can be deployed, what are the performance limits, etc.

Use Integration Tests to drive Design (more on how to do this in your projects in part 2) 08 Test: write tests to define which requests and responses must support each component of your application Use simple drivers for the requests and stubs to return examples for all the possible responses So: the team can work simultaneously in various components without integration problems the contracts and dependencies for the components are clear you can refactor anything inside as long as you respect the interface (pass the tests)

Use Unit Tests to find the best implementation (more on how to do this in your projects in part 2) 08 Test: write tests to understand what do you need of each class and method Test: write tests to show what inputs and outputs are supported So: anyone can use, extend or modify any class or component without breaking something your code is free of defects you write only what you need in some cases you can have more than one implementation (e.g. critical algorithms, drivers, transport/communication protocols)

Example: withdraw cash from an ATM 03

Unit test each component separately unit test unit test unit test 03

Integration test interaction of two or more components integration test integration test 03

System test usability, load, connectivity, deployment, etc . system test 03

Example: Web +integration of 3p services (GiffGaff) 03

Example: Web +integration of 3p services (GiffGaff) 03 ManInTheMiddle (developers) Selenium-IDE (developers) ManInTheMiddle (developers)

Example: Mobile +integration of 3p services (Walkopedia) 03 curl (developers)

XP through TDD

More Related Content

Viewers also liked (14)

Similar to XP through TDD (20)

Recently uploaded (20)

XP through TDD

Editor's Notes