|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 5
In addition to showcasing Easyb, this code snip shows the communication focus of ATDD tools. Automated acceptance criteria are expressed in high-level terms that makes sense to business managers as much as to software engineers and programmers. Most ATDD tools also generate reports that express the test results in familiar business terms. Tests that have been written in this way, but with no backing test code, will be marked as "pending." At the start of an iteration, all of the acceptance criteria will be in this state. As development progresses, the next step will be to implement them, which is where the actual code that tests the application is written. So these reports not only tell you what tests pass and fail, they also provide a way to track the progress of your project, by indicating what work remains to be done.
Taking a slightly broader perspective, automated acceptance tests are like any other automated tests -- they should be stored in your version control system and executed periodically on your Continuous Integration server (at least on a nightly basis, but preferably whenever a change is made to the application source code). Getting fast feedback when acceptance tests fail is essential. You can also configure your CI server to publish the results of the acceptance tests where they can be easily consulted by non-developers. Fortunately, modern CI tools such as Jenkins integrate well with virtually all of the common BDD tools.
When it comes to implementing ATDD for a web application, a wide range of open source and commercial tools are available. Given this wide range, choosing your tool with care is important; it can mean the difference between a set of automated acceptance tests that is easy to maintain in the future, and one that quickly becomes unusable due to prohibitive maintenance costs.
Modern automated web testing tools, both commercial and open source, fall into three categories:
Record/Replay tools, such Selenium IDE and JAutomate, let a user step through a web application, recording the user's actions as a test script. While tempting in its simplicity, this approach is in fact a poor strategy. The low-level scripts generated by these tools are fragile and hard to maintain. For example, there is no reuse of testing logic between scripts, which makes maintaining the scripts very costly.
Script-based testing is a slightly more flexible strategy. Tools such as Selenium, Watir, Canoo WebTest, and the commercial Quick Test Pro fall into this category. Tests are written in a programming language such as Java, Ruby, or VBScript. However this strategy is still quite low-level, focusing on the technical details of the web tests rather than the business requirements that they are testing. It also requires strong discipline and structure to avoid duplication within the scripts. Again, this tends to make tests more fragile and harder to maintain.
Good automated acceptance tests should be high level, expressed in business terms. They need to isolate the "what" from the "how." Doing so ensures that, if the implementation details for a particular screen should change, the changes would only minimally affect the low-level test code, and not the high-level tests. Ideally, you want to maintain a level of abstraction between what a web page does in business terms ("Approve an invoice"), and how it does it ("click the invoice in the invoice list, wait for the details to appear, then click on the Approve button").
Tools discussed in this article
More from JavaWorld