Test-Driven Development (TDD)
In Agile QA/Test team are sometimes called real managers as they demand that functionalities should be out on time and frequently so that they could complete testing of all the functionalities on time and so that team achieves their Iteration goals. But what happens when it doesn’t happens?
At the end of the Iteration you might have completed codes (what developers believes) but untested codes, not ready for Demo as per Definition of Done. – remember the Agile Principles “Working software is the primary measure of progress.“.
Non-completion of testing, is the major challenge why many sprints fails or teams not able to keep their promises (Iteration commitments).
Sometimes teams make Iterations longer expecting that they will be able to complete testing within Iteration – but remember the Agile Principles “Deliver working software frequently“.
Making iterations longer compromises on frequent feedback from customer. Manytimes this also results in low team productivity.
Sometimes organization is certified with certain ISO/CMM level/Six Sigma and need to maintain the high quality code commitment but sometime Agile team argue quality auditors, “hey!! we are agile team, we don’t worry about number of defects or defect density, we are more worried about working code and Demo”- remember “customer satisfaction through early and continuous delivery of valuable software.”
now remember if working and valuable software are buggy, the cost of maintenance later are higher, that’s why Agile team should also concentrate on other agile principles as well, “Continuous attention to technical excellence“, but with the delivery pressure, team ignores refactoring and due to financial reasons PO/Management many times don’t fund Refactoring. OR
How often you noticed a developer saying this?
- We don’t know what code is suppose to do, because either they don’t understand the requirements or big picture correctly or it’s legacy code
- We can’t prove that our code is working without someone manually verifying that it works
How often developers feels this?
- We need to debug the code to see what’s happening inside; many times root cause analysis takes much longer time.
- Let us write the code from scratch, can’t maintain this code.
So let’s find solution in Test-driven development and Refactoring.
Test-Driven Development (TDD)
What is TDD?
Test-driven development (TDD) is a software development process sometimes also called also called test-driven design. TDD is part of a larger software design paradigm known as Extreme Programming (XP). It’s one way to think through your requirements or design before you write your functional code.
Kent Beck, who is credited with having developed or ‘rediscovered’ the TDD technique. When asked to Kent why does he refers to the rediscovery (not the invention) of test-driven development he explained:
The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.
After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I refer to my role as “rediscovering” TDD.
Test-driven development can produce applications of high quality in less time than is possible with older methods.
Proper implementation of TDD requires the developers and testers to accurately anticipate how the application and its features will be used in the real world. Problems are approached in an incremental fashion and tests intended for the same unit of code must often be done many times over.
Three Laws of TDD (as per Robert Cecil Martin ‘Uncle Bob‘)
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
TDD is both an important agile requirements and agile design technique.
When we are using TDD practice, the Professional Attitude should be
- Think about the tests first
- Break the problem into smaller units
- Treat the test code on par with production code
- Have test as documentation of actual code
- No real design needed
- Takes too much time
- Too complex to learn
- TDD means write all tests first
Steps followed in TDD:
- The first step is to quickly add a test, basically just enough code to fail.
- Next you run your tests, often the complete test suite (automated), to ensure that the new test does in fact fail.
- You then update your functional code to make it pass the new tests.
- Then run your tests again.
- If they fail you need to update your functional code and retest.
- Once the tests pass the next step is to start over.
Resource: I recommend watching this video “What is Test Driven Development (TDD)? With an example”
Unit Testing: As Unit Testing is very important in TDD, make sure to write automated Unit Test suit using any of the xUnit frameworks, which is available for many languages, so that tests can be executed frequently, seamlessly and easily.
Regression Testing: Challenges with Traditional approach (Design -> Implement -> Test) of software development:
- Sometimes when you are writing/modifying code, more bugs are introduced than fixed.
- Regression bugs are very common – Situation: something used to work then stops working due to some new feature or bug-fix.
- Because of the threat of Regression bug, manual testing takes a very long time. – Retesting whole product: As product gets bigger, amount of time needed to test it becomes even more bigger.
- As code grows bigger, it becomes more and more fragile. – Chance of putting in bug when you are working on new code increased.
Solution: Automated tests and running them every time you change code base allows you
to verify, fix any new bug introduced immediately (quicker than long testing phase
at the end of development)
Refactoring is very important when following TDD.
TDD can be applied to any language and any IDE could be used
– C#, VB.NET, Java, Ruby, C++
– Eclipse, Visual Studio
– jUnit for Java
-nUnit for C#
– cppUnit for C++
– Mocking framework
– Refactoring plugins
– Continuous integration softwares
– Dependency injection framework
Benefits of TDD
- We Incrementally translated the requirements to test units
- We Concentrate on requirements/tests, then concentrate on implementation
- We only wrote as much code as we needed to make the tests pass
- Our tests helped us design our code
- We had to write testable code
- We couldn’t cheat and not write the tests
- Our tests are documentation of what our code does
- We can quickly regression test our code
- We know that our code is working
- We know that our code will continue to work
Please have a look at my blog on “Refactoring“.
@Mohammad Sami, Agile Coach
1,165 total views, 1 views today