TDD (Test Driven Development) is an development approach which create the test cases before coding directly. The purpose of the test case is to make sure what we coded are fulfilling the specifications. These test cases could be automated and re-run them without much effort. Hence, we could re-run whole test cases again to make sure the result is same for the coded unit. It could provide better quality for the application and developer could have confidence for their coding because of the test cases re-run.
In order to explain more clearly, let's take login function as an example we have three cases for this function, login success, login fail and duplicate login. With the TDD approach, we could build up all these test cases and assume this login function as the black box. Once test cases ready, build the login function and run these test cases to verify the output from the login function. This approach also gains another benefit for the further development. Because we may revise our login logic later (e.g. Password encryption and checking approach changed), we still could re-run these cases to confirm the changes won't after the outcome.
Actually, HomeBloc is trying to use as much as possible (As much as possible because we still skip some very simple test) of TDD approach, but sometimes these benefits are not obvious. Because the difference of the effort between the automated testing and manual testing is not apparent, especially during earlier stage. But once you built a complicated applications with a lot of functions, it should be very convenience that we have the automated test. We only need several clicks for the testing and know the result instantly.
BTW, someone may think that this approach is not worth since it needs some overhead to setup. And it is also not necessary to use such rigid approach to capture the bugs which may not occur. If you have any opinions on TDD, please feel free to share.
6 comments:
we would do one more step , we do it in BDD , more than just Test, but think about the Behavior on how user interact with the system. and we are using RSpec on Rails to do so.
Agreed with you and it is especially useful for the functions which are too abstract. But in practical reality, will we use these approaches for all functions? Sometimes, I think it maybe waste time for some simple functions (e.g. Maintenance function).
i think would be just depend on the importance. Like the core part of billing , reporting system , those part accept zero error , so have to be ensure that have to be bug free , or at least all those test case have to be pass.
But for the backend part , if time is limited , it is still acceptable to be non test case cover 100%.
Good point. It's good to practice it once in real life before starting to build. It's like a real rehearsal.
In terms of 演技, it's like 方法演技. Am I right?
In the matter of fact, I think TDD is such a good approach to reach a good designed code base. However the biggest problem I see is that you run the risk of the need to implement a feature that would require you to refactor your whole source code.
wanszezit: Yes, you are right.
Khaled Hussein:
Thanks for your concern. Actually, we also try to prevent refactoring whole source code and I just use it as the example to explain one of the benefits of TDD. Anyway, thanks for your clarification again.
Post a Comment