Presentation given at DDD Dublin on 9th October 2010. Covers common issues with TDD and ways to over come them.

1. C# TDD Painkillers @Ben_Hall Ben@BenHall.me.uk Blog.BenHall.me.uk CodeBetter.com/blogs/BenHall http://www.flickr.com/photos/pinksherbet/4004791663/

2. London based ASP.net MVPWeb Developer @ 7digital.com Open Source Developer WHO AM I? Co-Author Testing ASP.net Web Applications www.testingaspnet.com

3. You Test Design App Design

4. http://www.flickr.com/photos/chiotsrun/4115059294/sizes/l/

5. Test Design http://www.flickr.com/photos/nyuhuhuu/4442144329/

6. TDD doesn’t mean NUnit

7. TDD is about learning

8. TDD is about validating the unknowns Proving your own assumptions

9. Fundamentally the biggest TDD painkiller is not doing TDD

10. That’s why we have a QA department

11. Ideally Pairing Developer writing the testDeveloper writing the implementation

13. Write more tests to express more behaviour

14. Wouldn’t it be cool if...

15. Loose focus

16. Takes longer to achieve what you wanted to deliverDo the simplest thing possible.“First make it work, then make it right”

17. “TDD like you meant it”

18. http://www.flickr.com/photos/peasap/1625639532/sizes/l/ Spike

19. IRB (Ruby) Want rapid feedback Allows you to learn quickly

20. Spikes http://github.com/BenHall/CastleDynamicProxy101/blob/master/CastleDynamicProxy101/Program.cs http://github.com/BenHall/memcached101/blob/master/MemcacheDemo/Program.cs

21. NUnit makes learning repeatable Helps guide the learning during implementation

22. Test Naming and structure Pain killer

23. Each test should add something to explain the behaviour of the class under test As you read down then it should continue to add more information in a logical way Structure

26. Bad structure Method1_does_this Method2_does_this Method2_does_something_else Method1_does_not_do_this EXAMPLE

27. Bad structure Method1_does_this Method1_does_not_do_this Method2_does_this Method2_does_something_else EXAMPLE

28. Context Spec Taken from Ruby Example if the Persistent DLR integration

29. Naming of test Implementation I follow a BDD style which explains the behaviour If your naming talks about implementation, then your likely to test implementation – this could change! Like comments, you don’t want the test naming to be out of sync with what the actual test is doing

30. Actual test implementation Painkiller

31. Make sure the important details are easy to identify Hide the irrevent information to identify which bits are key Variable names can help with this varexpiredCreditCardDate = ... Highlight relevant data

32. Duplicated Setup in test Use Setup Make test helpers which have pre-defined stub configs EXAMPLE

33. Duplicated Setup in test Use Setup Make test helpers which have pre-defined stub configs EXAMPLE

35. Tests are documentation

36. IT DEPENDS

37. Given, When, Then

38. Scenario: Payment method has expired Given user John And John has expired credit card When I get the default payment method Then an invalid credit card will be returned Cuke4nuke SpecFlow

40. Design smells indicate it’s not done via TDD

41. Random, Dates, Machine Settings DateTime.Now(); new Random().Next();

42. DateTimefunc Random func Use staticFunc<T>

43. EXTERNAL DEPENDENCIES http://www.flickr.com/photos/gagilas/2659695352/

44. Fake the other side

45. Mock External Dependencies

46. Anti Corruption http://www.flickr.com/photos/aresauburnphotos/2678453389/sizes/l/

47. Mock Usage Not doing Unit Testing if you don’t use mocks Over usage ASP.net MVC is perfect example of having to do this Stubs return stubs returning stubs Too many mocks Mocking things you don’t own HttpContextBase IDbConnection

48. http://ayende.com/Blog/archive/2006/07/02/DoNOTMockSystemData.aspx

50. Fragile to refactoring Focusing too much on implementation Needs to be behaviour driven Incorrect Responsbilities

51. Running away from HttpContext

52. Interfaces establish behaviour boundaries. Stubock at boundaries

53. Let the tests drive the design Scares some people. But again, it’s a learning tool so let it educate you!

54. http://www.flickr.com/photos/yakobusan/2436481628/ Application Design

55. Dependencies IoC – Fear TDD + IoC + Dependencies can lead to a very different application design Fear is mainly because

56. Poor man’s IoC

57. REALLY?!?

60. Design Smell Responsibilities of the class being tested Fixture talks about lots of different concepts Context Spec makes this a lot easier to identify Easier to see if structured correctly Smell - Responsibilities http://www.flickr.com/photos/ricmcarthur/56268640/

61. Catalogue Handler Tests help indicate smells

62. Catalogue Handler Tests help indicate smells Abstract away? Combined service?

64. Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle

65. UI Testing http://blig.ig.com.br/brokenarrow/files/2009/04/too_many_toolbars.jpg

66. WPF Apps With The Model-View-ViewModel Design Pattern MVVM Pattern http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

67. MVP Pattern

68. MVP Pattern

69. Acceptance Test Driven Development

70. http://codebetter.com/blogs/benhall/archive/2010/03/16/testing-a-wpf-ui-using-ruby-cucumber-and-wipflash-dll.aspx

71. Scenario: Saving a product by name only Given the application has started And I enter the name "Product 1" When I save the product Then "Product 1" should be available to purchase

72. Given /^the application has started$/ do host = ApplicationLauncher.new @app = host.launch Dir.pwd + '/src/ExampleUIs/bin/Debug/ExampleUIs.exe' @main_window = @app.find_window 'petShopWindow' end Given /^I enter the name "([^quot;]*)"$/ do |product_name| textbox = @main_window.find_TextBox "petNameInput" textbox.text = product_name end When /^I save the product$/ do button = @main_window.find_Button "petSaveButton" button.click sleep(1) end Then /^"([^quot;]*)" should be available to purchase$/ do |product_name| combo = @main_window.find_ComboBox "basketInput" combo.Items.should include("Pet[#{product_name}]") end After do |scenario| @app.process.kill end

73. Full stack testing for ATDD? Waste of time! Feature coverage Can be used as part of a test metric

74. What’s good application design? When you read the code, it’s what you expect How quickly you can add tests How quickly you can implement new functionality Understandable by the team How much code churnework is being performed How much test coverage

75. Code Coverage Waste of time! Feature coverage Can be used as part of a test metric

76. Code and Test Reviews Better than metrics What the team thinks is good

77. 7digital XTCR – Cross Team Code Review At 7digital

79. It’s all about the mindset

80. Hardest part == getting started

81. Second hardest part == keep doing it

82. Becomes natural

83. Pair with someone http://www.flickr.com/photos/jasohill/65804069/sizes/l/

84. Kata http://www.flickr.com/photos/53511700@N06/4944542750/sizes/l/

85. Biggest Painkiller Lizard Brain Just do it! Fear http://www.flickr.com/photos/bartt/34937855/

86. End of the line http://www.flickr.com/photos/leon_homan/2856628778/

87. Summary Let the tests drive your design Listen for smells Fear – beat the lizard brain just do it!

88. @Ben_Hall Ben@BenHall.me.uk Blog.BenHall.me.uk http://www.flickr.com/photos/mike_c/4780493909/