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: shams@szazs.info
2
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: shams@szazs.info
3
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: shams@szazs.info
4
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: shams@szazs.info
6
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: shams@szazs.info
7
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: shams@szazs.info
8
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: shams@szazs.info
9
10. So here’s the thought of the day!
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
10
11. YOU CAN WRITE
BUG-FREE CODE!
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
11
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: shams@szazs.info
13
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: shams@szazs.info
14
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: shams@szazs.info
15
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: shams@szazs.info
16
17. So Let’s about the xDDs
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
17
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.
https://martinfowler.com/bliki/TestDrivenDevelopment.html
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
18
20. 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
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
20
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.
https://www.agilealliance.org/glossary/atdd/
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
21
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
https://www.agilealliance.org/glossary/bdd/
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
22
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: shams@szazs.info
24
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: shams@szazs.info
26
27. 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
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
27
28. So Let’s Talk about Tools
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
28
29. 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
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
29
33. 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
10/23/2018Shams Shaikh Twitter: @shamsulshaikh Email: shams@szazs.info
33
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: shams@szazs.info
38