Flexmonkey introduces unit testing into Flex user interface development

In the past 10 years, the use of automated unit test suites has been widely accepted, so that most developers are currently engaged in a number of test code writing, or at least feel that they do not write well. However, the continuous use of automated unit testing has created some confusion about who should test what. If developers need to overwrite unit tests in all of their code, does that mean that we no longer need a dedicated QA tester? Many development teams draw boundaries in the user interface, thinking that the user interface requires little coding or no coding at all, so it is more economical to have specialized testers hand-or use specialized test tools for testing. This division of labor tends to divide the test into "unit test" and "functional Test", where the developer is responsible for the former, and the QA Tester is responsible for the latter. This article explores Gorilla Logic's new Open source Flex user Interface Automation testing tool Flexmonkey to see how it can improve the productivity of developers and QA testers. Flexmonkey allows developers to incorporate user interface testing into unit test suites and continuous integration environments, and allows QA testers to extend those tests to integrated quality testing.

While the ultimate goal of the developer and QA testers is to ensure that the application works correctly, the primary goal of developer testing differs from QA. The goal of developer testing is to ensure that newly written or modified code works as intended without causing a "regression" (ie, inadvertently damaging the code that preceded the work). Automated regression testing is a vital part of agile development because only crazy developers will not have enough automated tests to ensure that the refactored code works after a lot of trivial code refactoring.

We have reason to expect developers to test each new piece of code, but automating each of these tests is unnecessary. Manual testing is very efficient for new or modified functions, but it is always impractical to prevent regression. To prevent regression, developers must provide the application with a series of Top-down and End-to-end tests, as well as evidence that even if automated testing is less than 50% code, it can effectively prevent regression in many applications.

QA testing is more nuanced than a developer's test because its goal is to ensure that the code works correctly in any conceivable usage scenario. In other words, the QA Tester's job is to destroy it by doing something terrible on the application. Of course, developers must be familiar with these so-called terrible things and they can do this test themselves, but this will make them really write code time becomes very little.

A qualified developer is tested with a test-first guideline that creates a small number of test cases to test it before the API itself is implemented, or by writing a point, measuring the criteria (code-a-Little-test-a-little, Caltal), That is, each developed code unit will be tested immediately after compiling. The caltal approach is particularly prevalent among user interface (UI) developers, but unlike APIs that define logical interfaces before implementation, Caltal does not have a good way to express how to test the user interface without actually implementing the interface and controlling the code.

Programmers generally rely primarily on the Xunit family's test framework to organize and execute unit tests. Xunit frameworks, such as JUnit and FlexUnit, can help developers manage a large number of automated test suites. With these frameworks, a single test suite can be run either individually or in combination, meaning that a test suite developed for one part of the system can run either independently or as part of a test complete system or a larger test suite throughout the application. In addition, the comprehensive reports provided by the framework make it easy for developers and managers to view summary and detailed test results. The Xunit test is a small program that itself can execute application code and check whether the actual results and expected results are consistent. The Xunit test suite provides a simple and efficient way to prevent regression. Most build systems, such as ant, provide direct support for running the Xunit test suite for the application build process. Continuous integration systems, such as cruise control or Hudson, automatically trigger these compilations every time the code is submitted to the team's versioning system, and help check if anyone in the team should be presented with a joke that does not pass through the test suite (these jokes will improve the development team's overall Efficiency is of paramount importance).