The document discusses test-driven development (TDD). TDD is a software development process where test cases are created to specify requirements before code is written to pass those tests. This ensures code meets requirements. Benefits of TDD include fewer bugs due to comprehensive testing, and ability to refactor code without breaking functionality. The document provides examples of different types of tests and outlines best practices for getting started with TDD.

1. Everything I Know
About TDD…
Well the Important Stuff
By: Joe Cisar
yourdais.com | 273-2692

2. Objectives
• What is TDD?
• Why use TDD?
• When should you use TDD?
• How?
yourdais.com | 273-2692

3. yourdais.com | 273-2692

4. Types of Tests
• Application Logic
• Unit – in process & single unit of logic
• Runs at build
• Functional/Integration – in process, full functions & focused on the functionality of a feature
vs. a single method
• Runs at build
• Acceptance/End to End – interacts with your system like any other application and asserts
against your dependencies (think of this as a separate codebase)
• Runs at release per environment
• Non-functional
• Load
• Performance
• Etc.
yourdais.com | 273-2692

5. Basic Test Structure
yourdais.com | 273-2692

6. So WHAT Is Test Driven Development (TDD)?
Wikipedia: Test-driven development (TDD) is a software development
process that relies on the repetition of a very short development cycle:
requirements are turned into very specific test cases, then the software is
improved so that the tests pass. This is opposed to software development
that allows software to be added that is not proven to meet requirements.
Note
• Nothing saying that it’s a specific type of test (Unit, Integration, Functional, UI,
etc.)
• Tests prove that your code meets requirements.
yourdais.com | 273-2692

7. yourdais.com | 273-2692
* Moving on from Refactor assumes all tests are passing after the refactor
Failing
Test
Refactor
Passing
Test
TDD
Passing
Test
Refactor
Passing
Test
Not TDD
This is what “drives” us to
make a code change
(aka develop)
If my tests are already
passing then nothing is
“driving” me to
change my code.

8. Why Test Drive?
• Isn’t TDD harder than just writing code?
• Yes! At first. Most things are, but with practice it will become part of how you develop.
• Won’t it take longer to deploy code and thus cost more?
• Yes! At first. You will be increasing the amount of code you write (albeit test code) significantly, but
will save time in the long run when you can refactor without fear of breaking things. The initial
investment in time and money is real but this will over time start to pay off, where un-tested code
only gets more costly as time goes on.
• Why not write my tests after I write my code?
• Writing the test first requires you to create code that is testable.
• Much easier to “skip” and move to the next thing.
• How do you know your test is properly failing?
• How do you know your code isn’t already doing what you want it to?
yourdais.com | 273-2692

9. Some Data (my team for ~2.5 years)
yourdais.com | 273-2692
%Bugs
# of
Stories
One bug for all
of 2019!

10. Oh no! A bug was found!
yourdais.com | 273-2692
What do
we do?!?

11. Using TDD to Prove and Remove a Bug
• Reproduce Bug
• Create a test to “prove” the bug (aka: failing test, aka: “red”)
• Arrange: Setup data the way that you reproduced the bug
• Act: Call the method causing the bug
• Assert: Make sure it does what it should (in this case it wont)
• Write the production code to fix the bug (aka: pass the test, aka: “green”)
yourdais.com | 273-2692
Code example:
https://github.com/RasicN/Demos/tree/master/TddPlayground

12. When Not to Test Drive?
yourdais.com | 273-2692
Not always the right approach!
• Two unknowns
• Know how to write the code but not the test?
• Know how to write the tests but not the code?
• Don’t know what code or tests to write?
• Proof of Concepts

13. Getting Started
• Get buy-in from everyone and make it a priority (easier said than done)
• Product Owner, Developers, Management, Stakeholders
• Find a new feature or project to start on, it will take longer than normal so
account for that
• Determine what types of tests will be most valuable to your team
• For us it is End to End and Functional Tests (as defined in the presentation)
yourdais.com | 273-2692

14. Functional Tests
yourdais.com | 273-2692
Service
Data Access
Controller
DB
3rd
Party
Logger
Functional Test
Arrange
Assert
Act

15. End To End Tests
yourdais.com | 273-2692
Service
Data Access
Controller
DB
3rd
Party
Logger
Incoming
RequestsEnd to End Test
Arrange
Assert
Act

16. Important Stuff!
• Figure out what types of tests are most valuable to your team and focus
there
• Don’t be an extremist one way or the other
• Please don’t focus on Code Coverage
• Leave the day on a failing test
• Practice!
yourdais.com | 273-2692

17. Great Testing Tools (.Net Stack)
• NCrunch: https://www.ncrunch.net/
• Wallaby: https://wallabyjs.com/
• Fluent Assertions: https://fluentassertions.com/
• SpecFlow: https://specflow.org/
• CodeWars: https://www.codewars.com
• NSubstitute: https://nsubstitute.github.io/
• Ninject: https://github.com/ninject/Ninject
• Random Test Values: https://github.com/RasicN/random-test-values
yourdais.com | 273-2692

18. Questions?
yourdais.com | 273-2692