"Development" test-driven flex development-using FlexUnit

http://elromdesign.com/blog/2010/03/10/test-driven-development-tdd-with-flexunit-4-complete-tutorial/

Originally intended to complete the translation of this blog post, while translating, while talking about their understanding of the drive test development. Of course, my understanding is not necessarily the same as that of the original author, but at least we all admit that the development is test-driven. However, CSDN's blog system is really unable to understand "unable to large space CP come over", then I quote this article. Talk a little bit about my understanding of test-driven development.

This article is undoubtedly well worth seeing, with detailed examples demonstrating the development of test-driven. In a framework such as Flex, which is focused on the interface, test-driven is essential. In fact, it is not difficult to understand this article, people who are familiar with flex may not be bothered to see this kind of tutorial, I think the main purpose of this article is to emphasize the importance of test-driven development, especially under the framework of Flex.

The traditional software process, the test is independent of the development part, (I am happy to discuss software engineering things), the developer completed the development of the test to the tester, found the problem, the developer changes, and then test. There seems to be no problem, the problem is the cost, such a change brought about by the time consumption is considerable, especially in the case of frequent changes in demand. The reason for emphasizing test-driven development under Flex is that flex is biased towards the client and is biased towards the interface. The appearance is the most easily changed part of the whole software system, everyone's definition of the interface is different, so in the project iterative process will bring a lot of changes in the interface, if these interfaces coupled with business logic, and no test code, the cost of this modification can be imagined, You never know if there are any hidden bugs in the system, and you never know whether a change needs to be done without impacting the original business logic.

One of the benefits of testing-driven development is to avoid situations where developers have already written all of the code in the process of writing a program, so any changes that need to be performed over the original test will confirm that the change is within expectations. Another added benefit is the ability to allow developers more time to organize their ideas, consider the architectural design issues of the entire project, usually developers always get the requirements and then start coding, even if the current task is completed, but if the problem is not considered as a whole, in the short term it seems that demand is satisfied, But in the event of a change in demand, this change may have to be re-implemented again. The test-driven development is to reduce the probability of the occurrence of this situation as much as possible. Test-driven development requires developers to decouple the relatively independent process from the software for testing, because the business logic that is coupled to the interface design cannot be tested.

Usually, the novice developer always thinks that the function is generated randomly, writes to a line, well, here needs a function, well then write a function, as to the function parameters, function name, return type is arbitrary, can complete the things at hand. However, these naturally occurring development habits are undoubtedly a big mistake in the development of frequent demand changes. What may happen in such a situation is that late changes will cause the changes that have already been made to be re-entered into the change process, and the reason for this is that there is no correct understanding of the changes that may still exist in the late stages when the change occurred. From another point of view, test-driven development will help developers grow, as the focus from coding to the complete architecture is undoubtedly a big leap forward.

However, I am not saying that all people are concerned about the architecture, the change is not a problem, you can borrow the above view, so that: when the level of developers to improve, then the change is easy to deal with. Start experimenting with test-driven development, which in my opinion is undoubtedly the beginning of a promotion.