CodeAndroid meetup Test Driven Development
Objectives Brief history of TDD Do a very basic test
<ul>Apologies upfront: Easily excited Talk fast Australian accent Large area to explain Questions, Slow down </ul>
“ The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 %) chance of introduc...
Today: Test Driven Development
<ul>Test Driven Development History </ul>
<ul>Toyota Production System by Taiichi Ohno </ul><ul>Competing with US companies was difficult. Smaller production runs o...
<ul>How is making cars anything like making software ? </ul><ul><li>Complex processes
Unable to be “explained” to the layman
Like Ohno, we have waste </li><ul><li>Time
Money
Energy </li></ul></ul>
Traditional model: Implementation Requirements Design Verification Maintenance
<ul>Unsurprisingly... </ul><ul><li>As a programmer, you will be caught in the waterfall model.
Your manager/your client will have provided the specs, and you now need to “follow the process”
You are a cog in the machine. </li></ul>
Manufacturing & construction industries Software has requirements that are never in spec. Requirements evolve over time ...
Manufacturing & construction industries BDUF meant changes later on were costly Software is difficult to change in maint...
<ul>How do you do it ? </ul>
<ul>The rules of fight club. </ul><ul><li>1. Write new code only if an automated test has failed.
2. Eliminate duplication. </li></ul>
<ul>“ These are two simple rules, but they generate complex individual and group behavior with technical implications” Ken...
Próximos SlideShares
Carregando em…5
×

Test Driven Development: Part 2

7.004 visualizações

Publicada em

by Wade Mealing

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
no profile picture user

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
7.004
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4.261
Ações
Compartilhamentos
0
Downloads
26
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Test Driven Development: Part 2

  1. 1. CodeAndroid meetup Test Driven Development
  2. 2. Objectives Brief history of TDD Do a very basic test
  3. 3. <ul>Apologies upfront: Easily excited Talk fast Australian accent Large area to explain Questions, Slow down </ul>
  4. 4. “ The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 %) chance of introducing another defect.” Mythical Man Month
  5. 5. Today: Test Driven Development
  6. 6. <ul>Test Driven Development History </ul>
  7. 7. <ul>Toyota Production System by Taiichi Ohno </ul><ul>Competing with US companies was difficult. Smaller production runs of more models Waste when production runs finished and there were left over parts <li>Ohno reverse engineered the production line and created “Just in time” manufacturing </li></ul>
  8. 8. <ul>How is making cars anything like making software ? </ul><ul><li>Complex processes
  9. 9. Unable to be “explained” to the layman
  10. 10. Like Ohno, we have waste </li><ul><li>Time
  11. 11. Money
  12. 12. Energy </li></ul></ul>
  13. 13. Traditional model: Implementation Requirements Design Verification Maintenance
  14. 14. <ul>Unsurprisingly... </ul><ul><li>As a programmer, you will be caught in the waterfall model.
  15. 15. Your manager/your client will have provided the specs, and you now need to “follow the process”
  16. 16. You are a cog in the machine. </li></ul>
  17. 17. Manufacturing & construction industries Software has requirements that are never in spec. Requirements evolve over time Software developers are rarely domain experts BDUF meant changes later on were costly Waterfall model is based on “Physical Design”
  18. 18. Manufacturing & construction industries BDUF meant changes later on were costly Software is difficult to change in maintenance Two teams same project.
  19. 19. <ul>How do you do it ? </ul>
  20. 20. <ul>The rules of fight club. </ul><ul><li>1. Write new code only if an automated test has failed.
  21. 21. 2. Eliminate duplication. </li></ul>
  22. 22. <ul>“ These are two simple rules, but they generate complex individual and group behavior with technical implications” Kent Beck </ul>
  23. 23. <ul>Unsurprisingly... </ul><ul><li>As a programmer, you will be caught in the waterfall model.
  24. 24. Your manager/your client will have provided the specs, and you now need to “follow the process”
  25. 25. You are a cog in the machine. </li></ul>
  26. 26. FAIL FAIL <ul>Writing massive amounts of tests up front is “time expensive”, so with a goal in mind you can follow this flow chart. (Everyone loves flow charts) </ul>Add a test Run the tests Change Run the tests
  27. 27. <ul>Tests shouldn't take long to write. Tests shouldn't take long to run. The drive the “development” of the application. Write what it takes to make the test pass, and that is all. YNGNIA </ul>
  28. 28. Live programming demo
  29. 29. Useful URLs: android-sdk/platforms/android-1.5/samples/ApiDemos My life with android (mylifewithandroid.blogspot.com) Diego Torres Milano's blog (dtmilano.blogspot.com)
  30. 30. “ The fundamental problem with program maintenance is that fixing a defect has a substantial (20-50 %) chance of introducing another defect.” Mythical Man Month
  31. 31. CodeAndroid.org <ul><li>Android Developer/User Group </li></ul><ul><li>Grassroots effort by developers </li></ul><ul><li>Promote Android development around this region (SEA, Oceania) </li></ul><ul><li>You can join us on Facebook, Twitter (codeandroid), IRC (#codeandroid @ irc.freenode.net) </li></ul>Special thanks to Google for the venue and food.

×