Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Test Driven Development
Transcript of Test Driven Development
The Value of Software
Have you ever heard this?
"We need to put less effort on quality so we can build more features for our next release"
so... what's TDD?
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
Self Testing Code
You only code functional code in response of testing failing first
Think about the interface first
Thinking about the test first forces you to think about the interface first. This focus on interface and how you use a class helps you separate interface and implementation
Don't fear Refactoring
You create a suit of test that you trust with your life, otherwise you won't be able to refactor without the fear of breaking something out
Test-Driven Development (TDD) is a technique for building software that
development by writing
tests. It was developed
by Kent Beck in the late
1990's as part of
In essence you follow three simple steps repeatedly
"The most common way that I hear to screw up TDD is neglecting the third step.
code to keep it
clean is a key
part of the
you just end up
with a messy aggregation of code fragment" - Martin Fowler
so it seems maintaining the code clean it's pretty important to make TDD works... but why? let's talk about that before continuing with TDD
Good Modular Design
Pleasant User Interface
visible to user and customers
Debt Metaphor (Ward Cunningham)
Effort to Add New Feature
Cost of Poor Design
The Land that Scrum Forgot
ok, I got it, so maintaining the code clean and software design is important but how I do that?
Design Stamina Hypothesis
Code Base Complexity
Effort for New Features
Technical Practices (XP)
We need to have some concepts clear before doing TDD. Let´s see Test Automation
Mike Cohn (Succeding With Agile)
Kent Beck & Erich Gamma (JUnit creators)
Ron Jeffries, list of xUnit frameworks online:
Unit Test Basic Structure
Unit Test Conventions
Create a Unit Test per Implementation Class (typically its named with the name of the Class being tested with the prefix 'Test')
Every unit test can be executed in any order which means that they must be independent from each other
If you end up doing something like: Arrange, Act, Assert, Act, Assert, Arrange more, Act, Assert; you are trying the test more than one thing at a time. It's better to do more than one unit test per method if necessary, That way the test results will be more accurate to tell you what's going wrong
It's a good practice to name the unit test method in a way that it's easy to know what method is being tested, the precondition to the test and the expected result.
Test Driven Development Example
That was a little intro to Unit Testing. Now it's time for a little example of TDD solving a problem
In the editors we use it daily, for text, graphics, sound and so on, we are happy to have functionality to Undo and Redo mistakes we make.
There is a certain logic to how the undo-redo system works. You know it by heart surely, but just to get you started TDD'ing will give it a try. "Command" is anything that manipulates our document in the editor, eg. adding or deleting some text.
If we add command 1 and then command 2, we can undo 2 (but not undo 1, nor redo anything). Then we can undo 1 or redo 2 (but not carry out any other undo/redo).
If we undo 1, then we can only redo 1, and then we can redo 2
If we add command 1, then command 2, then undo 2, then add command 3, we can undo 3. When we undo 3, we can then redo 3 or undo 1. When we undo 1, we can redo 1. If we redo 1, we can then undo 1 or redo 3.
You can checkout the code on:
You can also review the code history on:
Every commit was intended to be a TDD step while resolving the Undo-Redo Stack problem. Hope you enjoy it.
So that's it, hope it was helpful, if you want further info in these topics, I highly recommend checking the links below
The value of Software Design - Martin Fowler
(look for 'Martin Fowler - Software Design in the 21st Century' on youtube, this talk starts at 44:53)
Debt Methaphor - Ward Cunningham
(also on youtube)
The land that scrum forgot - Robert C. Martin