Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test First Development in C# using Open Source Tools


Published on

Presented at All Things Open 2018
Presented by Shamsul Shaikh with Charles Schwab
10/23/18 - 2:00 PM - Programming Languages

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Test First Development in C# using Open Source Tools

  1. 1. Test First Development in C# using Open Source Tools Shams Shaikh All Things Open 2018
  2. 2. Objectives  Beginner Level Introduction to Test First Development (TFD)  Give enough to explore further in confidence  Some Code Examples to Get You Started 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 2
  3. 3. Let’s Know About You?  I want to learn about TFD and I have not done TFD before.  I already use some form of Test First Development (TDD/BDD/ATDD) and want to refresh/solidify the concepts and see what others have to say about it.  Oh My God!! I absolutely love TFD and I am glad there is another nutcase just like me.  I absolutely hate TFD and I am going to make sure nobody ever uses TFD as it is a piece of $@%@!  Eeny meeny miny moe, Catch a Tiger By the Toe. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 3
  4. 4. How I used to code  Think of what I want to develop  Write some code.  Test your code  Running the whole executable .. manually testing it.  Writing some helper executable that run some parts of the code.  Hand it over to some one to test it  Repeat the last 2 steps until the someone says is complete. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 4
  5. 5. Paradigm Shift 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 5
  6. 6. Procedural Programming vs Object Oriented Programming  First Paradigm Shift  Everything was Functions and I was getting pretty handy with dividing everything into functions.  So what is this class & object thingy  Finally one day it was clear (lightbulb)  I had been walking backwards all this time and wow I am now actually moving forwards. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 6
  7. 7. So what does it mean to do Test First Development  Think of the capabilities what you want to build  Let’s Document It  Then Let’s Build It 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 7
  8. 8. Getting Things Done by David Allen  Capture  In a world full of distractions, this is the main step!!  Process  Organize  Review  Engage 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 8
  9. 9. A conversation from the past …  I don’t need to write unit tests because I have thoroughly tested my code.  And yes his code really did work well!!  My arguments …  We need to be able to repeat these wonderful tests later and thus should be documented. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 9
  10. 10. So here’s the thought of the day! 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 10
  11. 11. YOU CAN WRITE BUG-FREE CODE! 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 11
  12. 12. Yes Really!! 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 12
  13. 13. How?  As long as you only write code for the tests you have.  Resist the temptation of improving the code just because you can  Oh Wait!!  Improving the Code?  Don’t you mean you just discovered a new scenario/use case. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 13
  14. 14. Paradigm Shift PreTFD  QA tries to find issues/bugs in code after the code is written.  Bugs are found after code is written. TFD  QA helps find the scenarios/use cases that the code is written for.  There are no bugs.  We may find unhandled scenarios after the initial tests are written. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 14
  15. 15. So will we find new scenarios/use cases after the code is written using TFD  Of course we will  Expect to find new scenarios all the time  Already Handled  Not Yet Handled  Add new Tests for these new scenarios immediately.  Expect this to happen and it is absolutely OK. We are after all humans.  If any scenario is found post-development scenario discovery phase, the focus should be on how we can improve so that we could have discovered these scenarios early. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 15
  16. 16. So is QA folks are required?  If we are using TFD, why have QA at all?  Some teams have completely removed the QA role from their team.  Well …  We still need the skill of being able to come up with scenarios/use cases  We still need to be able to discover new scenarios.  In TFD, the effort should be more towards finding the scenarios early. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 16
  17. 17. So Let’s about the xDDs 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 17
  18. 18. Test Driven Development  Follow three simple steps repeatedly:  Write a test for the next bit of functionality you want to add.  Write the functional code until the test passes.  Refactor both new and old code to make it well structured.  10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 18
  19. 19. More TDD bdd/ 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 19
  20. 20. TDD Resources  Test Driven Development: By Example Kent Beck  Book/test_driven_development.html   Numerous Resources on Pluralsight & SafariBooks 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 20
  21. 21. Acceptance Test Driven Development  Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about...).  These acceptance tests represent the user's point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.  10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 21
  22. 22. Behavior Driven Development  Behaviour Driven Development (BDD) is a synthesis and refinement of practices stemming from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD). BDD augments TDD and ATDD with the following tactics:  Apply the "Five Why's" principle to each proposed user story, so that its purpose is clearly related to business outcomes  thinking "from the outside in", in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste  describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication  apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap  10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 22
  23. 23. Hybrid xDDs ( 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 23
  24. 24. Software Testability  Controllability: The degree to which it is possible to control the state of the component under test (CUT) as required for testing.  Observability: The degree to which it is possible to observe (intermediate and final) test results.  Isolateability: The degree to which the component under test (CUT) can be tested in isolation.  Separation of concerns: The degree to which the component under test has a single, well defined responsibility.  Understandability: The degree to which the component under test is documented or self-explaining.  Automatability: The degree to which it is possible to automate testing of the component under test.  Heterogeneity: The degree to which the use of diverse technologies requires to use diverse test methods and tools in parallel. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 24
  25. 25. Designing for Testability: SOLID Design Principles  SRP – Single Responsibility Principle.  OCP – Open/Closed Principle.  LSP – Liskov Substitution Principle.  ISP – Interface Segregation Principle.  DIP – Dependency Inversion Principle. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 25
  26. 26. Isolation  Think of a Computer System  Each component is tested separately  Once Put Together – It is supposed to work  They are tested together to make sure everything works well together.  How can you isolate?  Dummies, Stubs, Fakes, Spies, Mocks 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 26
  27. 27. Is TDD Dead?  A discussion between Martin Fowler, Kent Beck, David H. Hansson  TDD and Confidence  Test-induced Design Damage  Over Mocking (a three level deep mocking)  Over Designing (Just for the sake of designing)  Feedback and QA  Cost of Testing  Answering   testing.html 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 27
  28. 28. So Let’s Talk about Tools 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 28
  29. 29. Moq -  Strong-typed: no strings for expectations, no object-typed return values or constraints  Unsurpassed VS IntelliSense integration: everything supports full VS IntelliSense, from setting expectations, to specifying method call arguments, return values, etc.  No Record/Replay idioms to learn. Just construct your mock, set it up, use it and optionally verify calls to it (you may not verify mocks when they act as stubs only, or when you are doing more classic state- based testing by checking returned values from the object under test)  VERY low learning curve as a consequence of the previous three points. For the most part, you don't even need to ever read the documentation.  Granular control over mock behavior with a simple MockBehavior enumeration (no need to learn what's the theoretical difference between a mock, a stub, a fake, a dynamic mock, etc.)  Mock both interfaces and classes  Override expectations: can set default expectations in a fixture setup, and override as needed on tests  Pass constructor arguments for mocked classes  Intercept and raise events on mocks  Intuitive support for out/ref arguments 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 29
  30. 30. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 30
  31. 31. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 31
  32. 32. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 32
  33. 33. WireMock.Net - Net/WireMock.Net  HTTP response stubbing, matchable on URL/Path, headers, cookies and body content patterns  Runs in unit tests, as a standalone process, as windows service, as Azure or IIS or as docker  Configurable via a fluent DotNet API, JSON files and JSON over HTTP  Record/playback of stubs  Per-request conditional proxying  Stateful behaviour simulation  Configurable response delays 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 33
  34. 34. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 34
  35. 35. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 35
  36. 36. SpecFlow -  Cucumber for .NET  Uses Gherkin to allow writing tests in “Natural Language” 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 36
  37. 37. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 37
  38. 38. Is TFD right for you?  It is really upto you.  I have had my Paradigm Shift, will you?  No it is definitely not dead. 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 38
  39. 39. Thank you & Questions Email: Twitter: @shamsulshaikh 10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: 39