Test First Development in C# using Open Source Tools

Test First Development
in C# using Open Source
Tools
Shams Shaikh
All Things Open 2018

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: shams@szazs.info
2

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.
3

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.
4

Paradigm Shift
5

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.
6

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
7

Getting Things Done by David Allen
 Capture
 In a world full of distractions, this is the main step!!
 Process
 Organize
 Review
 Engage
8

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.
9

So here’s the thought of the day!
10

YOU CAN WRITE
BUG-FREE CODE!
11

Yes Really!!
12

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.
13

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.
14

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.
15

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.
16

So Let’s about the xDDs
17

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.
 https://martinfowler.com/bliki/TestDrivenDevelopment.html
18

More TDD
https://blog.testlodge.com/tdd-vs-
bdd/
19

TDD Resources
 Test Driven Development: By Example Kent Beck
 https://www.jamesshore.com/Agile-
Book/test_driven_development.html
 https://www.agilealliance.org/glossary/tdd/
 Numerous Resources on Pluralsight & SafariBooks
20

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.
 https://www.agilealliance.org/glossary/atdd/
21

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
 https://www.agilealliance.org/glossary/bdd/
22

Hybrid xDDs
(https://blog.testlodge.com/tdd-vs-bdd/)
23

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.
24

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.
25

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
26

Is TDD Dead? https://martinfowler.com/articles/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
 https://www.facebook.com/notes/kent-beck/rip-tdd/750840194948847/
 http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-
testing.html
27

So Let’s Talk about Tools
28

Moq - https://github.com/moq/moq4
 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
29

30

31

32

WireMock.Net - https://github.com/WireMock-
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
33

34

35

SpecFlow - https://github.com/techtalk/SpecFlow
 Cucumber for .NET
 Uses Gherkin to allow writing tests in “Natural Language”
36

37

Is TFD right for you?
 It is really upto you.
 I have had my Paradigm Shift, will you?
 No it is definitely not dead.
38

Thank you & Questions
Email: shams@szazs.info Twitter: @shamsulshaikh
39

Test First Development in C# using Open Source Tools

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von All Things Open

Mehr von All Things Open (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Test First Development in C# using Open Source Tools