The document discusses test driven development (TDD) in an agile environment. It covers topics like the agile manifesto, evolutionary design, TDD steps and philosophy, myths about TDD, test qualities, benefits and costs of TDD, plugins and language support. The author shares their experience with TDD, noting that it improved code quality and refactoring while requiring support from leads to be effective long-term. Acceptance TDD is recommended to ensure shared understanding of what is being built.

1. hugeinc.com
info@hugeinc.com
45 Main St. #220 Brooklyn, NY 11222
+1 718 625 4843
Nov20, 2013
TDD

2. Test Driven Development
In An Agile Environment.

3. • Agile Manifesto
• Evolutionary Development and Design
• TDD introduction
• TDD Philosophy and Implementation
• TDD Myths
• TDD test qualities
• TDD Current trends
• TDD Plugins
• TDD Languages & Framework Support
• What Next… ? Acceptance TDD
• Experience with TDD
Topics Covered
.

4. • Composed by heavy hitters in the software industry in
Snowbird, UT in February 2001.
• Included the folks backing methodologies such as Scrum,
XP, Crystal ,Feature driven development, etc.
• Big names included such as Martin Fowler, Robert C
Martin( Uncle Bob), Alistair Cockburn, Ken Schwaber etc.
Agile Manifesto
.

5. Agile Manifesto - Continued
.
• Continuous delivery & Integration
• Welcome changing reqs
• Deliver working software frequently
• Involve biz and developers throughout the project
• Build projects around motivated folks
• Communication should be facetoface
• Primary metric of progress is working software
• All participants should maintain a constant pace
• Continuous attention to tech excellence & good design
• Simplicity is essential
• Self organizing teams
• Periodic retrospectives

6. Evolutionary Design & Development
.
Scott Ambler.
Evolutionary development is an iterative and incremental
approach to software development.
Instead of creating a comprehensive artifact, such as a requirements
specification, that you review and accept before creating a
comprehensive design model (and so on) you instead evolve the critical
development artifacts over time in an iterative manner.
Instead of building and then delivering your system in a single “big bang”
release you instead deliver it incrementally over time. Yes, you will likely
still need to do some initial requirements and architecture envisioning,
but this is at a high level I can't say this enough, you don't need to do
big modeling upfront (BMUF)

7. Legacy Way…. This is how I knew
.
Development and Testing.
Mostly implies a waterfall/bigbang process
Very little emphasis on unit testing by developers
Tests are almost developed as an afterthought
Tests are mostly manual
Huge emphasis on QA team
Delivering quality software on time and within budget is almost
accidental

8. What Agile thinks...
.
About development and testing.
Strong emphasis on testing.
Strong emphasis on continuous integration.
Once all software is ready for delivery, all tests should pass.
A unique way to address modern challenges in software development.

9. Quotes
.
If it's worth building, it's worth testing.
If it's not worth testing, why are you wasting your time working on it?

10. What is TDD?
.
It’s a crazy idea with Best one.
Generally, If crazy idea and it works then its fantastic.
If fantastic idea and it works who cares as already some one thought
about it.

11. Test Driven Dvlp (TDD) Philosophy
.
The basic tenets are developing and implementing unit tests
before writing a line of code
Unit tests will and must fail up front
Code is developed after the test is developed.
A unique idea that is still foreign to many developers
This does not imply that we must use an agile development
process.

12. TDD Steps
.

13. TDD Steps… continued.
.
• Quickly add a test just enough code to fail test
• Run testsuite to ensure test fails (may choose to run a subset of suite)
• Update your functional code to ensure new test passes
• Rerun test suite and keep updating functional code until test passes
• Refactor and move on

14. Myths about TDD
.
Myth: TDD is ok for small projects involving a handful of folks but won't scale
to large projects involving scores or hundreds of people.
Answer: Not true.
Kent Beck worked on a pure TDD project developed in Smalltalk.
4 years and 40 man years of effort resulting in 250K lines of func code and
250K lines of test code
4,000 tests run in under 20 mins
Full suite runs several times a day

15. Myths … Continued
.
Myth: So writing a test before start code development, is that TDD at all?
Answer: Not true…!
TDD is not unit testing philosophy, Rather it’s a practice , how to approach
the implementation. When new functionality pops up ,TDD focus rather than
Imagine how to implement it, if thinks how to test it. It’s the different way of
approaching the solution.
So in short, TDD tries to break the initial solution approach into two parts of
Test and Development. It thinks,…well first how we gonna we test it and then
shapes the development in Smaller, easier focus logic to concentrate.
It similar to Agile where Project has been broken into Sprints, Sprint has been
broken in to Stories, Stories has been broken into tasks….. And TDD breaks
task into smaller, testable business logic.

16. Myths … Continued
.
Myth: Many people think Test before code is crazy idea. TDD Makes your
speed down & less productive.
Answer: Not true…!
Industry wide study and research stats Teams who adapts TDD gets faster
over the time. It makes code refactor in development and production easier
and flawless.
TDD helps team to have nice sleep in deployment phase of project.
Eg. Staging and Pre-prod phase of Royal Caribbean.

17. Myths … Continued
.
Myth: I was reading a developer report. It was written TDD had negative
influence on code quality.
Answer: Not true…!
The most important thing to remember about TDD is that the concept
contains both testing and development.
It implies that we must consider implementation and testing as two parallel
activities – we cannot ignore one and only focus on the other.

18. Myths … Continued
.
Myth: No one knows TDD. Otherwise it would be everywhere.
Answer: Not true…!
Large portion of developers has been exposed to TDD since last 5 years. Myth
looks true due to very less adoption ratio. And the one of the reason ( Out of
many is) social barrier.
I see only two class in my Team. And I am a programmer not QA. I cannot
write tests.

19. Agile Developer
.

20. Agile Developer
.
• Agile programmers are pros because they take things like software quality very
seriously.
• The best are passionate testers who take pride in their work and are always
looking for an edge in writing higher-quality code.
• To that end, there are certain things agile programmers do when regularly
creating high-quality, production-ready software.
• They write lots of tests and will often use tests as a means of driving out their
designs.
• They are continuously designing and improving the architecture of their software
as they go.
• They make sure the code base is always in a state of production readiness and
ready to deploy at a moment’s notice.

21. Agile Tester
.

22. Agile Tester
.
• Agile testers know that although it’s one thing to build it, it is another to know it
works.
• Agile tester will insert themselves into the agile project early, ensuring that
success for user stories gets defined up front and that when working software is
produced, it works.
• Agile tester work closely with developers, helping with test automation, looking
for holes, and doing extensive exploratory testing by trying to break the
application from all possible angles.
• Agile Tester have in mind the big testing picture and never lose site of load
testing, scalability, and anything else the team could be doing to produce high-
quality software.

23. Ideal qualities of Tests
.
• Decisive – Test should be human communication filter. It should
determine success/failure of a program and each time it should help to
advance to next level.
• Complete Test should read like a story. It should contains all the
information it needs to run correctly with a given test harness and work
artifact under test.
• Valid – produces a result that matches the intention of the work artifact
under test
• Repeatable always gives the same results if the test harness and the
artifact under test are the same i.e. Is deterministic
• Isolated is not affected by other tests run before it nor does a test affect
the results of tests run after it
• Automated requires only a start signal in order to run to completion in a
finite amount of time

24. TDD benefits
.
• Shortens the programming feedback
• It promotes to take small steps and helps to achieve functionality with
small steps progressively.
• Provides detailed (executable) specifications
• Promotes development of high-quality code
• Provides concrete evidence that your code works
• Requires developers to prove it with code
• Provides finely grained, concrete feedback (in mins)
• Ensures that your design is clean by focusing on creation of operations
that are callable and testable
• Supports evolutionary development
• Defects after deployment are rare and non critical. Much difference than
Legacy way of development.

25. TDD Costs
.
• Cost of learning curve. Initial dip in productivity, but quality deliverable
starts from day one.
• Testing slows down rapid prototyping( For Startup projects or POCs)
• Need to deal with Social barrier.
At the end its Subjective decision either its costly or not costly.
Quick example in Lexus.
Great debate still goes on . Test first or Test last. It depends upon
circumstances.

26. TDD Pluggins
.
Junit-Max
Infinitest
Mockito
Jdave
Cucumber
Jacoco
Programmer loves to make their life of living programmer.
Test Prioritization.
Testing patterns.
Speed of Tests.
Integration with Code for less time test results.

27. TDD Language Support
.
Java. It has very good support. Smart IDES like Eclipse, Intellij compiles and
Test the code without any such efforts. You just type and test. Frameworks
like Spring, Struts make life so easy. Most of the time you don’t need to run
the server at all.
Not good languages for Programmer and TDD.
C : Its possible to make C language TDD, but its very hard and verbose. Tons
of code and scripts needed.
C++ : It needs real code refactoring in terms of development, Tons of shell
scripts, custom solution to tweak compliers, very laborious and hard to
maintain.

28. My experience
.
“All right… we know what TDD is and understand the importance of Tests but you
know… one day tests stared to fail and then one day we got override of it.”
This nonsense seems to be common in across the industry. Aristotle should be
shocked if he would hear this. If test is not running, means my program isn't running.
Don’t deliver it.
In practical, this happens as programmers faces lot pressure apart from programming.
They can’t convenience non-Tech leads about the process and quality.
So the first and most important thing in TDD is
Support from Leads.

29. Acceptance TDD … to overcome above
problem
.
• Acceptance Test Driven Development (ATDD) is a practice in which the
whole team collaboratively discusses acceptance criteria, with examples,
and then distills them into a set of concrete acceptance tests before
development begins.
• It’s the best way I know to ensure that we all have the same shared
understanding of what it is we’re actually building.
• It’s also the best way known to ensure we have a shared definition of
Done.

30. My experience … Continued
.
TDD is not to write Unit Test first before Code.
Its philosophy and very highly articulated practice , it needs time to understand, digest
and make it in practice in day to day work.
Next question… Are we following TDD in Lexus? I don’t think so, but we are trying.
I think … the day when Programmer thinks first about Test before Code
implementation and Tests drive the design of software implementation, deliveries
then we would be on path of TDD.

31. My experience … Continued
.
I found a partner in my Pair-programming model.
TDD helped me a lot to refactor my own code, too quite extent.
IT helped to cover many scenarios which I would never imagine in development.
Writing code in small testable components and then plug them together is such nice
idea, which resulted in almost negligible code reviews.
This partner stand by side for decision on implementation design.
If its tested and working who will bother you at the end.

32. My experience … Continued
.
Can we preach/enforce the TDD to be used across company or departments???
May be… or may be not.
Note from Kent Beck :
Kent Beck, founder of TDD, Junit and Testing framework in software did this for 10
years and at the end .. decided to shut his mouth.
He follows the practice of self learn, improve his own practice , create presentations,
try to set model for cleaner, faster development process to other programmers.
The best way is to mandate code test coverage to certain limit (70%) with tool like
Jacoco.
Extensive use of Code Review tools like Fisheye certainly helps to point out the team
what is the best way to test your code.

33. Questions?…
Comments?...

34. hugeinc.com
info@hugeinc.com
45 Main St. #220 Brooklyn, NY 11222
+1 718 625 4843