Test-Driven Development

Test-Driven
Development
By: Ny Fanilo Andrianjafy
Demo: Romain Rocès

What I am going to talk about
● What is TDD ?
● Tests clarity and readability
● Mocks
● Behavior-Driven Development
● The goals
2

Source: http://blogs.msdn.com/b/seliot/archive/2011/04/25/i-don-t-always-test-my-code-but-when-i-do-i-do-it-in-production.aspx 3

What is Test-Driven Development
Lifecycle whose capital concept is:
Writing just enough code to satisfy specific conditions and continuously
refactoring the code afterward.
Repetition of very short development cycles.
Everything starts with a red sign.
4

It helps you to think
Requirements are likely to be separated in small testable pieces of code.
You know how to use your code before writing it.
Edge cases can be discovered before anything is deployed.
5

Source: https://github.com/mjhea0/flaskr-tdd
6

Setup and Teardown
Setup and clean up the test environment for the object you are testing.
Keep it clear and simple.
Complicated setup is a good sign of poor tests organization and design..
If tests actually need complicated setup, decouple them from the tests. (e.g. Shared file)
8

Setup and Tear Down
Source: http://www.slideshare.net/fitc_slideshare/the-little-shop-of-tdd-horrors-53208388
9

Tests coverage
Not testing 100% of your code lines does not makes you a bad person.
Using the above sentence to your advantage to write very few tests and
eventually omit the fundamental of your code makes you a bad person.
Not all conditions/paths are tested.
10

Tests are code
Treat your tests well.
Keep them readable.
Never write tests that nobody wants or is able to read. You may have to re-read them someday.
The good practice you have in mind when writing production code should also
be on your mind when writing the tests.
Do not let them become garbage.
11

Clarity
The clarity of expectations is golden for others.
Naming your tests is important, do not worry about the length.
Write good descriptions.
Be lazy. Anybody should be able to look at the test and understand.
Arrange, Act, Assert. (AAA) Separate them. Space your code.
12

You will not write nice code on first try
TDD is a lifecycle, the last step is refactoring
Refactor only on green. Not before, satisfy the tests first.
You will have multiple iterations of refactor, sometimes small, sometimes a tad
bigger.
One advice: time box
Example: 30 minute lifecycle (or what pleases you)
10 minutes of writing tests
10 minutes of writing code
13

Network Responses
You might need to have tests that checks the sanity of external API’s
Be clear about your expectations.
Tests are code: do not ignore the performance issues and bottlenecks.
It is a good idea to create a separate environment for tests that really go to the
server.
15

Mock
When mocking data: mock only what you need. Do not load an entire Model for
nothing.
16

Behavior
Focus on testing software behaviors rather that single unit of code.
Group tests and behaviors that are tied together.
Connect similar behavior using keywords like with/when/given.
Be aware of complexity
Being unable to organize tests easily might be caused by confusing requirements.
The key is: Scenarios => Use Cases => Behaviors
18

Goals
Profitable: The tests should be profitable. It should give you a value
Maintainability: It helps your software to be maintainable
Common understanding
Validate the understanding of behaviors
Quality
20

Test-Driven Development

More Related Content

What's hot (20)

Similar to Test-Driven Development (20)

Recently uploaded (20)

Test-Driven Development