It has similar aspects as taza, with regard to elements and flows. Actually, a lot of what's in taza is something I discussed with some of the developers who released this when I was contracting for GID.
Currently, it's only configured to take screen shots automatically when links are clicked but the user can take a screen shot anytime they wish: TestExtention.screen_shot($current_test_method, 'pre') I plan on adding an option to disable automatic screen shots. Also, watir has been extended to that Watir::Element includes methods to see if an element is in the view able area and to scroll to the element: https://github.com/ccyphers/qa_robusta/blob/master/qa_observer/sites/demo/test_cases/test_element_scroll_to.rb It's not intended to work with per se, cucumber, rspec or other frameworks. For now I want to stick with minitest but might add some of minitest spec features in. Personally, I feel that having a good separation and flow to the test framework where test case writers can make simple calls to perform their testing is more important than test case syntax. Zeljko, I look forward to discussing this in more details in an up coming screencast. I most likely won't be able to get to this until next week. On Thu, Oct 6, 2011 at 2:52 PM, Chuck van der Linden <[email protected]> wrote: > Cliff, > > How does this framework compare with watirspash, taza, or watircraft? > > What things are you doing that they are not, and vise versa? > > Why might somone want to use this framwork as opposed to one of the > others? > > How well does your framework work and play with Specification by > Example tools such as RSpec and Cucumber? > > Is it possible to configure things so that screenshots are taken only > when an assert or .should is failing, instead of on every link or > button click? > > On Oct 3, 10:09 am, Cliff <[email protected]> wrote: >> Hello Watir Community >> >> I've been a fan of Watir for web based automation for many years now >> and would like to introduce a framework intended to provide the means >> for creating system level test cases. What is meant by system level >> test cases? As a tester when you manually test an application often >> times you find yourself not only testing a web interface but having to >> login to a remote unix machine and verify some results. With QA >> Robusta writing test cases interfacing with multiple interface types >> is a breeze. Right now, only remote unix support is provided but I'll >> be adding remote windows as well using psexec. >> Seehttps://cyberconnect.biz/opensource/qa_robusta.htmlfor complete >> details. Be sure to check out a demo report as >> wellhttps://cyberconnect.biz/opensource/demo_results.html. >> >> * Elements, such as links, buttons, and other html objects are defined >> in one location. This ensures over >> time the user won't have definitions spread out throughout different >> layers of code requiring time >> consuming updates if the application under test is modified. >> * Well defined flows allows the user to have a common means for >> navigating and controlling interactions >> with the application under test. This takes all logic out of test >> classes and yields in higher more modular >> code re-use. >> * When an application requiring testing has the elements and flows >> implemented less code savy resources >> can easily add new test cases once trained on how to access the >> flows and elements. >> * When ever a link or button is clicked a screen shot is taken >> * Results are available under site/results directory in html format. >> Report includes the rdoc on a per test class >> method along with any screen shots taken. >> * Transparent remote Unix command execution leading to well defined >> interfaces for common task. For example, >> one may have a class defined specifically for RemoteUnixNetwork. >> This class would have methods such as, >> assign_ip, ifup, ifdown, etc. This class then would be able to >> perform these task on any remote Unix machine. >> * Executes the same on Windows or Linux/Unix environments. Developers >> have the freedom to develop on the >> platform of choice. >> * Mechanize extension: Allows the user to define a web application's >> page elements in a YAML format and provide >> navigation paths accessing the YAML structure to interact with the >> web application. Users can also perform direct >> http.post or any other mechanize functionality when defining state- >> full interfaces to hit a web application without >> going through a browser. >> >> Happy Testing >> Cliff. > > -- > Before posting, please read http://watir.com/support. In short: search before > you ask, be nice. > > [email protected] > http://groups.google.com/group/watir-general > [email protected] > -- Before posting, please read http://watir.com/support. In short: search before you ask, be nice. [email protected] http://groups.google.com/group/watir-general [email protected]
