Download as PDF, PPTX
![Practicing at home?
every day [0]
a few times each month [2]
Have you ever practiced a Kata by
yourself at home?
material copyright Bache consulting, emily@bacheconsulting.com
Friday, 13 May 2011](https://image.slidesharecdn.com/introcodingdojoxp2011-110513025642-phpapp01/85/Teaching-and-Learning-TDD-in-the-Coding-Dojo-56-320.jpg)
![Practicing at home?
every day [0]
a few times each month [2]
Have you ever practiced a Kata by
yourself at home?
material copyright Bache consulting, emily@bacheconsulting.com
Friday, 13 May 2011](https://image.slidesharecdn.com/introcodingdojoxp2011-110513025642-phpapp01/75/Teaching-and-Learning-TDD-in-the-Coding-Dojo-56-2048.jpg)
Uploaded byEmily Bache
Teaching and Learning TDD in the Coding Dojo
The document outlines a session on Test-Driven Development (TDD) presented by Emily Bache, discussing its importance for developers, the process of TDD, and how to learn it through coding dojos. It emphasizes the distinction between manual testing and automated checks while promoting collaborative practices for effective software development. Additionally, the document includes information on dojo meetings, coding exercises, and resources for further exploration of TDD.
Teaching and Learning TDD in the Coding Dojo
- 1. The Coder’s Dojo Emily Bache emily@bacheconsulting.com http://emilybache.blogspot.com material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 2. Session outline Why should developers test? (slides) What is TDD? (slides) TDD vs Test Last (slides, discussion) How can I learn TDD? (slides) Randori (coding) Experiences leading Coding Dojos (slides, discussion) material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 3. Why should developers Test? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 4. Traditional Testing Strategy: Bug reports Code releases Text Testers Developers The Wall images from iconspedia.com: Asher, DaPino Webdesign, Zeus Box, MazenI77, Harwen, Flahorn, eponas-deeway material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 5. Developers are blindto bugs Developers don’t want to break their beautiful creation Subconciously use their knowledge of the implementation to avoid weak spots circa 1940, Paris, Blindfold typing competition (Jhayne, flickr) material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 6. A smart mouse... material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 7. JUnit “Keep the bar green to keep the code clean” material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 8. Engineering practices (Exploratory) Testing Automated Checks Continuous Integration Automated Build Version Control Friday, 13 May 2011
- 9. Testing vs Checking Requires a sapient Can be automated human confirms our beliefs to be turns up new true information asks the same question asks new questions as yesterday is exploration and is making sure the learning program doesn’t fail See also Michael Bolton’s article http://www.developsense.com/blog/2009/08/testing-vs-checking/ Friday, 13 May 2011
- 10. Example - Fitnesse material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 11. Testers and Devson same team Timebox Frequent communication Working Software Testers Developers The team delivers working, tested software every iteration images from iconspedia.com: Asher, DaPino Webdesign, Zeus Box, MazenI77, Harwen, Flahorn, eponas-deeway material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 12. Automated Checks Catch regression errors - Safety net for refactoring Documentation/examples of usage Force internal interfaces/ modules/units material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 13. What is TDD? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 14. Bob Martin’s Lawsof TDD Red Refactor Green Don’t write production code unless it is to make a failing unit test pass. Don’t write any more of a unit test than is sufficient to fail. Don’t write any more production code than is sufficient to pass the one failing unit test. http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd Friday, 13 May 2011
- 15. TDD moves Starting Red Analyse Problem Declare & Name Test List Arrange-Act-Assert Guiding Test Satisfy compiler Refactor Green Remove Fake Implement solution Remove Code Smell Fake it (No new functionality) Start over Note new test cases material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 16. TDD moves (starting) Basic analysis of problem Review existing code in area Starting Identify where the new functionality Analyse Problem will be called from Test List Guiding Test Guiding Test (take from story acceptance criteria) Make a list of test cases Move On When: You have an achievable goal & have chosen first test material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 17. TDD moves (getto red) Declare and name a test Red Arrange - Act - Assert (start Declare & Name Arrange-Act-Assert with Assert) Satisfy compiler Just enough Production code to satisfy compiler Move On When: Test code describes missing function, executes, and is Red material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 18. TDD moves (getto Green) Change the production code - implement just enough to make the test pass Green Implement solution Fake it Fake it (if you’re unsure) Start over When all else fails, remove the failing test, get back to green, and write an easier test. Move On When: Tests all execute and are Green material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 19. TDD moves (refactor) Change production code: remove fakes, code smells Refactor Change test code: improve Remove Fake readability Remove Code Smell (No new functionality) Note new test cases Don’t add functionality not required by tests. Note down new test cases on list. Move On When: Code is Clean, tests all execute and are Green material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 20. Why TDD overTest Last? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 21. TDD vs TestLast Write code Red Refactor Green Debug Write tests Friday, 13 May 2011
- 22. TDD & feedback Writing a failing test tells you: what problem you are solving Red if your SUT requires many collaborators Refactor Green if SUT has an inconvenient API before you commit to an implementation Friday, 13 May 2011
- 23. TDD & feedback Red Getting to Green: makes you write only just enough functionality Refactor Green Avoid over design & code bloat Friday, 13 May 2011
- 24. TDD & feedback Red Refactoring happens frequently Refactor Green Many opportunities to improve your design Friday, 13 May 2011
- 25. TDD - nosilver bullet “TDD constrains the problem space we are looking at, as well as provides feedback on how well we are addressing this problem. Of course TDD isn't the only thing imposing constraints on us, nor our only source of feedback.” - David Tchepak From his article http://www.davesquared.net/2011/03/why-learning-tdd-is-hard-and-what-to-do.html Friday, 13 May 2011
- 26. Checking & Testing Write code Red Refactor Green Debug Write tests TDD -> more like Testing Test-Last -> more like Checking TDD is a lot more fun to do Friday, 13 May 2011
- 27.
- 28. Should developers doTDD? Do you test your own code? Do you need separate testers? What can developers do to influence the long term project velocity? (give examples) Do you think it matters whether you write the tests first or last? Friday, 13 May 2011
- 29. How can Ilearn TDD? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 30. read books, blogs,code... other people’s experience and wisdom read code, discuss code, analyse code - that you didn’t write yourself material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 31. Pair Programming Attribution: flickr user Lisamarie Babik material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 32. The Coder’s Dojo • The dojo is the place where you go every week to practice and learn karate see http://codingdojo.org Friday, 13 May 2011
- 33. Code Kata: TDDmoves ‘Pragmatic’ Dave Thomas material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 34. KataRomanNumerals Write a program to convert normal numbers to roman numerals: 1 --> I 10 --> X 7 --> VII material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 35. KataMinesweeper Write a program that outputs the same field including the hint numbers, like this *... *100 .... 2210 .*.. 1*10 .... 1110 material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 36. What happens ata dojo meeting? 3 – 10 programmers meet as equals do some coding together practice TDD moves Image courtesy Danilo Sato material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 37. Prepared Kata One person presents their best solution They have practiced it many times. Group contributes feedback and questions material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 38. Screencasts Watching someone else code music or commentary material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 39. Randori Everyone contributes Split into pairs, or work all together on a projector Ping pong TDD or time limits material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 40. Dojo Rules The person with the key- board decides what to type Ask for help if stuck, offer help if asked Be strict about TDD Offer design criticism on a green bar material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 41. Test-Infected You’re writing some code using TDD, awkward and slow and unfamiliar. You refactor it. Some tests fail unexpectedly! You realize the tests saved you That feeling of safety You want more of that! material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 42. Importance of safe Step outside normal hierarchy Mistakes expected Moderation/leadership important material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 43. Dojo Discussions The code you write in the dojo leads to concrete discussions PartnerData newPartner = new PartnerData("Disney"); AddressData address = new AddressData("24 Stars Ave", "91210", "Hollywood", "USA")); newPartner.setAddress(address); UserData contact = new UserData("Emily", "emily@test.com", "031 123456"); newPartner.setContactPerson(contact); Friday, 13 May 2011
- 44. Dojo Discussions PartnerDatanewPartner = new PartnerData("Disney") .withAddress( new AddressData("24 Stars Ave", "91210", "Hollywood", "USA")) .withContactPerson( new UserData("Emily", "emily@test.com", "031 123456")); Is this better? Cleaner? Friday, 13 May 2011
- 45. The Coders Dojo Emily Bache emily@bacheconsulting.com http://emilybache.blogspot.com material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 46. Experiences material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 47. Different kinds ofgroups language user groups with colleagues in the same team open/free taught course agile coach leading course at a client material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 48. Language user groups .js Python, Ruby, JavaScript, Scala groups Small numbers of skilled enthusiasts Dojo meetings are fun! material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 49. With colleagues Stop work a little early, dojo in evening Boss sponsors with time & pizza Fun, community building material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 50. Open/free taught course JDojo@Gbg 5 sessions announced in advance as a course 4pm - 6pm (may count as work) Host company uses it for marketing & recruitment material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 51. Agile coach leadsdojo at client Raise competency in whole dept/team Discuss: what is clean code for this team? “This would never work on our code” images from iconspedia.com: Asher, DaPino Webdesign, Zeus Box, MazenI77, Harwen, Flahorn, eponas-deeway material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 52. What past participants have learnt material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 53. Survey of variousdojos 29 responses, most have been to more than one kind material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 54. Based on 4-5meetings... Roughly how many dojo meetings have you been to? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 55. Well received Would you encourage others who want to improve their programming skills to come to dojo meetings? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 56. Practicing at home? every day [0] a few times each month [2] Have you ever practiced a Kata by yourself at home? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 57. We asked about: TDD Mocking Refactoring IDE & frameworks Language skills Image attribution: Flickr user crashmaster material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 58. Language Skill Scale from 1-5 beginner - expert How comfortable were/are you with the programming language? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 59. Comfortable with IDE Scale from 1-5 beginner - expert How comfortable were/are you with the IDE-editor? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 60. Mock objects Scale from 1-5 beginner - expert How good were/are you at using Mock objects? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 61. Refactoring Scale from 1-5 beginner - expert How good at refactoring were/are you? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 62. Write Unit TestsOften? Scale from 1-5 never - daily How often did/do you write unit tests? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 63. Test-Driven Development Scale from 1-5 beginner - expert How good at Test-Driven Development were/are you? material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 64. How to getstarted material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 65. You could joina dojo! Lots of them exist already It's fun, rewarding and you get to meet new people Or, hire a coach to run one at your company! Image attribution: Flickr user lumaxart material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 66. You could starta dojo! || + + tools: meetup.com, google groups persuade a friend to help organize Get someone to pay for pizza! images from iconspedia.com: Asher, DaPino Webdesign, Zeus Box, MazenI77, Harwen, Flahorn, eponas-deeway material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 67. Online Resources http://codingdojo.org http://codingkata.org http://codersdojo.org http://cyber-dojo.com http://katacasts.com http://katacatalog.com material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 68. Still trying stuffout... give out kata in advance? what to do with code afterwards? groups for beginners and different groups for experts? if/when to bring in legacy code what form to use when? (prepared, randori, pairs etc) material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011
- 69. The Coders Dojo Emily Bache emily@bacheconsulting.com http://emilybache.blogspot.com material copyright Bache consulting, emily@bacheconsulting.com Friday, 13 May 2011