The famous rod johnson, the increasingly popular agile methodology, the potential XP branch, and the XP core TDD, and what is good, the special transfer is as follows:
http://www.theserverside.com/news/thread.tss?thread_id=32394#160253Why do I like TDD? 1) by the nature of software engineering any code needs refactoring. Having code covered with unit-tests, gives me confidence during the refactoring. I do not know any other reliable way of having the same kind of confidence. Without the confidence, I would be afraid to do refactorings often, which would make the software product of lesser quality.
1) Essentially, all code in software development requires reconstruction. The code covered by unit test allows me to have confidence. I don't know what other ways can make me gain so confidence. If there is no confidence, then I don't have a serious reconciliation, which must also affect the quality of the code. 2) Due to the Nature of Unit-tests (Emphasize: Unit), IT IS IMPOSIBLE TO TEST A "Badly-Smelling" Code. In Order to Be Able To Unit-Test Your Code, IT Has To Be Cleaner, And Better Designed : Short, Focused Methods, Writing to Interfaces, Lously Coupled etc. Due to the natural characteristics of the unit test (note that the unit test) is unable to unit test the code with "bad taste". In order to be able to smooth your code, your code will gradually become more clear, the design is more perfect: the code is short, the focus, and the interface programming, reducing coupling.
I think, this might not have been something that was foreseen initially but discovered later My guess is, initially, people just wanted to make computer do what it is best for -. Repetitive work (in this case - testing) and have code test the application, not humans But as a "byproduct" they noticed that testing requires design improvement, too When they discovered it, somebody smart-enough had an idea -..? if it is so, why not write tests first Design is supposed to come BEFORE The Implementation and if Tests Affect Design, It Makes Sense To Write Them Before The Implementation, TOO.
I think maybe the advocate that the unit test has never expected that it has confirmed this already. I think, just starting people just want to play the characteristics of the computer, let it complete the repetitive work (herein refer to test), and no longer need people to test. But they found "by-products" - Test needs better design. Then, the outstanding people in them put forward a new idea - in this case, why not write a test in advance? The design should be before the code implementation, and if the test can affect the design, don't you write a test before the code implementation? And the TDD Started ...
So TDD started ...... .. ============================================= http: //www.theserverside.com/news/thread. ?. tss thread_id = 32394 # 160294 I think I agree with some of the objections raised with TDD, but the problem seems more with how people use it than a basic flaw in the concept The 2 primary objections raised are: 1. There is a lot of test-centric coding with less focus on ensuring overall business requirement is fulfilled. 2. Developers seem to think that having run the product through the Unit tests ensures that the product is well-tested and production ready. I caused for the TDD The problem is very agreed, but the problem is more in how people solve it, not only to stay in basic ideas. The main problems mainly caused by TDD are: 1. There are too many "test-centered" code, while less focusing on overall business needs. 2. Developers seem to begin to think that running unit tests can guarantee the product's testing and product quality. All that TDD should be expected to do is run a sanity check at the end of a new build to ensure that the contracts that each unit of code is supposed to fulfill have not been broken. You still need to go through your entire QA cycle to ensure you have a functional product. So, the automated unit tests are just additional checks and do not replace QA. But, unfortunately I have seen situations where people believe that once they have a proper build and unit tested they can reduce the time they spend In Qa. NOTRLES TRUE !!! IT Just Ensures That If The Unit Tests WERE WRITTEN PROPERLY, The Quality of The Code Reaching Qa Will Be a little better. All TDD can do one check after the end of the project is completed Work, guarantees that the contract between the original unit is not broken. After the project is completed, a Quality Assurance process is required to ensure the function of the entire project. That is to say, the automated test is only an additional check, not a full replacement of quality assurance. But unfortunately, people I have seen are not. They think that once the unit test is successful, then the time on the QA is reduced. But the fact is really not the case.
