TDD-Test Driven Development
Dark secret behind TDD is - TDD has nothing to do with testing its all about requirements and design driven development.
TDD is an approach for software development where developers write unit tests before start working on actual implementation.Here our tests represents the requirements that we will be implementing.So unit tests in TDD drives the design and development of code.
Whenever new feature is to be developed,unit tests are written first.At first all tests must fail because the implementation for those tests is not there.If your tests are pass then the functionality you will be developing is already present there so no need to duplicate the code.Once your tests fails then you start developing the code which will pass those tests.This will result in avoiding writing unecesary code which is not required.Once all the tests are passed you can refactor the code to make it upto the standards.
The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests.
Before TDD people follows the traditional approach as People read the requirements or get requirements from stake holders or product owner and come up with some details and then come up with architecture design, code analysis , db design, etc.. and then later start writing the code and write tests around the newly developed functionality.once this is tested, they would unearth bugs and bugs would be logged for the same, so here there is back and forth between developer and tester.
Which increases the cycle of development and releasing the product or release
In TDD people will start writing test cases, which would obviously fail at the first hand as there is no code or functionality written so far to satisfy the test.
Now, team would start writing code to pass the test and indirectly address the functionality to make sure the tests pass, in this way basically the code is more qualitative and the number of to and fros would be minimized.
The steps in TDD are:
1. Write a test that tests a specific part of the user story or feature you're developing.
2. Run the test. It should fail right now, because you haven't written any code yet. If your test doesn't fail your existing code already behaves correctly or more likely your test doesn't test anything.
3. Make the simplest possible change to your code that ensures the test succeeds. It's important that you do not make changes that go beyond your test, even if you know that you're going to change that later. This ensures that you do not introduce behavior that is untested because in TDD your tests are a major part of your documentation. It is also important that you do not touch anything that is unrelated to the test your trying to satisfy.
4. Run your test again. It should now succeed. But if it fails go back to 1. Make sure that your test is actually correct before you try to find the problem in your code.
5. When your test is satisfied refactor your code. Since in step 3 you did not touch anything unrelated to the test you may have introduced code smells. But because all of your existing code is now fully covered by tests (one of the reasons why TDD would be used in the first place) you can now safely reorganize it, and as long as your tests still succeed you're doing it right.
There are three stages in TDD drive approAch for modern software development.First one is RED stage,GREEN Stage and third one is refactor.
In RED stage,developers write tests for missing behaviour and when executed those tests will fail because desired implementation is not implemented yet.
In Green stage,minimal code that makes the failing tests to pass is written and no extra code is written.
In Reactoring,as in GREEN stage we have written minimal code to pass ths the failing tests,here in this stage code refactoring is done to make code to the coding standards and remove any other code smells.
Test driven development is a micro cycle that needs to follow throughout the development. Ideally the code written with TDD approach should have:
1.All the test pass
2.It has no duplication
3.It communicates its intent
4.No unwanted parts exist
One of the chief limitations of TDD is the fact that tests can sometimes be incorrectly conceived or applied. This may result in units that do not perform as expected in the real world. Even if all the units work perfectly in isolation in all anticipated scenarios, end users may encounter situations not imagined by the developers and testers.
The final results of TDD are only as good as the tests that have been used, the thoroughness with which they have been done and the extent to which they mimic conditions encountered by users of the final product.
Comments
Post a Comment