Lessons Learnt from
Test-Driven Development
By: Anand Powar
Once Upon A Time
Our product has got quality issues
Manager Developer
We lack a good QA, lets hire one
6 Months Later...
Our development is slowing down
Manager Developer
There is just too much workload,
we need to introduce a shadow resource
“One bad programmer can easily
create two new jobs a year.”
David Parnas
The Problem
?
Good
Cheap Fast
No Silver Bullet
Good
Cheap Fast
However
A bit better
A bit cheaper A bit faster
Test-Driven
Development
Test Driven Development
Write
new test
New
require-
ment
Run
tests
Write
new
code
Run
tests
Refactor
Run
tests
Make it Fail
Make it Work
Make it Better
It’s a lot like going to the gym
Build your confidence
Use TDD where it's suitable, mix other styles
Only test things that can possibly break
Avoid bad design trade-offs
Yes, we still need QA
“Imperfect tests, run frequently, are
much better than perfect tests that
are never written at all”
Martin Fowler
Practical
Lego Game
Acceptance criteria:
It should be 4 inches tall
Our hypothesis: 4 inches is the ideal size
It should be able to walk
At least 2 legs
It should be able to jump
If I drop it from a height of 2 inches, it should not break
Build a toy dinosaur
5 minutes
Children want a bigger dinosaur
6 inches tall
Time to market
We need to beat the competition
Market Feedback
ASAP
Can your dinosaur still jump?
“If you don’t like unit testing your
product, most likely your customers
won’t like to test it either.”
Anonymous
Thanks
Get connected
http://in.linkedin.com/in/anandpowar
http://twitter.com/anandpowar

Lessons learnt from test driven development

Editor's Notes

  • #2 Hello everyone, My name is Anand and today I will be talking about 1. my experience while working with teams using TDD And later 2. We will follow this by playing fun game using lego bricks
  • #3 Let me tell you a story, One day my manager had a meeting with the client where the client raised quality concerns
  • #4 There was another complaint And again, I told him it’s not my fault And then we hired an intern
  • #5 Thus proving who developed the concept of information hiding in modular programming (encapsulation)
  • #6 So, you see, in order to achieve good quality and have a faster development we sacrificed on the 3rd angle: cheap In software development , we all have been looking for a technique which could help us produce good, fast and cheap s/w Do you know one ?
  • #7 what i have realized is that there is no silver bullet
  • #8 In Agile, there are a number of practices which can help make the s/w a bit better, a bit faster and a bit cheaper And TDD being one of them.
  • #9 This is the TDD cycle, Here you write a unit test that doesn‘t work Then you Make the test work quickly (committing whatever sins necessary) And then you eliminate all of the duplication created in merely getting the test to work Loose coupling
  • #10 You know it is good for you, all the arguments make sense, so you start working out. There's an initial rush, which is great, but after a few days you start to wonder if it is worth the trouble. You're taking an hour out of your day to change your clothes and run on a treadmill and you're not sure you're really gaining anything other than sore legs and arms. Then, after maybe one or two weeks, just as the soreness is going away, a Big Deadline begins approaching. You need to spend every waking hour trying to get "useful" work done, so you cut out extraneous stuff, like going to the gym. You fall out of the habit, and by the time Big Deadline is over, you're back to square one. If you manage to make it back to the gym at all, you feel just as sore as you were the first time you went. You do some reading, to see if you're doing something wrong. You begin feel a little bit of irrational spite toward all the fit, happy people extolling the virtues of exercise. You realize that you don't have a lot in common. They don't have to drive 15 minutes out of the way to go to the gym; there is one in their building. They don't have to argue with anybody about the benefits of exercise; it is just something everybody does and accepts as important. When a Big Deadline approaches, they aren't told that exercise is unnecessary any more than your boss would ask you to stop eating. http://stackoverflow.com/a/69263
  • #11 Practice.
  • #12 Remember the TDD is not a silver bullet. Depending upon the situation you should consider other styles: plain unit tests, BDD, ATDD and even manual testing http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html http://martinfowler.com/articles/is-tdd-dead/
  • #13 We need not achieve 100% code coverage so my advise is to write tests for code that is prone to change. Ignore extensively 3rd party libraries and other reusable components As a developer you aren't paid to write tests, you just write enough to be confident
  • #14 TDD is not just a testing technique but also a way to design your application architecture. When starting with TDD it's good to have a mentor who is knows about the common mistakes that developers make. Do pair programming with them.
  • #15 Last but not the least
  • #17 form groups of 5-6 people Identify observers
  • #23 Did you unit test? Remind about the initial acceptance criteria. What did we learn?