tdd in agile
TRANSCRIPT
Test Driven Development In An Agile Environment.
• 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
.
• 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
.
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 face to face• 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
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 up front (BMUF)
Legacy Way…. This is how I knew
.
Development and Testing.
Mostly implies a waterfall/big bang process Very little emphasis on unit testing by developers Tests are almost developed as an afterthought Tests are mostly manualHuge emphasis on QA team Delivering quality software on time and within budget is almost accidental
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.
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?
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.
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.
TDD Steps
.
TDD Steps… continued.
.
• Quickly add a test just enough code to fail test • Run test suite to ensure test fails (may choose to run a subset of suite) • Update your functional code to ensure new test passes • Re run test suite and keep updating functional code until test passes • Refactor and move on
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 minsFull suite runs several times a day
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.
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.
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.
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.
Agile Developer
.
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.
Agile Tester
.
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.
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
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.
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.
TDD Pluggins
.
Junit-MaxInfinitestMockitoJdaveCucumberJacoco
Programmer loves to make their life of living programmer.
Test Prioritization.Testing patterns.Speed of Tests.Integration with Code for less time test results.
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.
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.
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.
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.
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.
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.
Questions?…Comments?...
[email protected] Main St. #220 Brooklyn, NY 11222+1 718 625 4843