Re: [Wtr-general] Handling multiple versions of a website [advice needed]
On 10/25/06, John Lolis [EMAIL PROTECTED] wrote: Thanks for the input davemunns, its nice to hear from someone who is so far along in a project.My only real fear is that of maintaining such a giant library. If you were to leave your company tomorrow, would someone be able to pick it up in time before it got too out of date? I have a framework along the lines of Mr. Munn's, but mine is organized more along the lines of verbs than of nouns. I have a high-level controller capable of calling any number of actions implemented in a middle level. Each of the middle-level actions may use a set of tag-level libraries for our app, kept in a set of low-level scripts. All of the Watir happens at the lowest level; all of the actions in the middle and upper layers are domain-specific. My framework isn't good enough to detect GUI changes automatically, but I could do that if I had to. As for designing one of these yourself, read this article from Kevin Lawrence: http://www.developertesting.com/archives/GrowYourHarness.pdf . If you don't understand it right away, read it again, and again, until you do. This is exactly how you create a large, effective, maintainable test framework. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Handling multiple versions of a website [advice needed]
John Lolis wrote: Has anyone thought of a good way of managing such changes? Do you make one giant 'mapping' class and just update that as needed? Do you store the Watir calls and generate code around them? I have a library of some 1250 lines of code. Although some of it was written as a result of refactoring working tests along the lines that Kevin Lawrence writes about in the article cited by Chris, most was directly test driven by specific tests that were designed to test-drive the automation framework. I have 700 lines of such tests. These of course are in addition to the tests that were written to test our application. I believe that simple tests of your framework are the best way to detect problems. They can be used to verify that the framework matches up to the application. Bret ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] Handling multiple versions of a website [advice needed]
Looking for some feed back on this topic. To start, I'm attempting to automate a very large and very complex web application. Watir is great at handling all the strange controls (it has some timing issues with frames and modal dialogs, but those are known issues). The problem I now face is how to keep my tests from become outdated in a fast moving environment. Its simple enough to wrap Watir calls in objects (for example a Login object) so that I can write a test case and use Login(name,pass) instead of ie.link(yadayada).click. The problem comes when you have 20+ objects currently (and it will probably grow 10 fold) and all of them contain Watir code. When a new version of the web site comes out I predict tracking down the problems (and adding switches to handle old versions) would quickly make the project unmaintainable. Has anyone thought of a good way of managing such changes? Do you make one giant 'mapping' class and just update that as needed? Do you store the Watir calls and generate code around them? Any insight from someone who has been through this would be great :) - Posted via Jive Forums http://forums.openqa.org/thread.jspa?threadID=4936messageID=13707#13707 ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Handling multiple versions of a website [advice needed]
I have written a product testing tool that automates the navigation (detecting GUI changes) through 320+ classes in a web-based gui. It also generates performance measurements. The tool is designed in 3 levels ( each in an rb file): 1) the high level test classes (named to easily map to the GUI object screen labels) and a main method with navigation steps, 2) a middle level that processes table row and column data, and 3) a low level that identifies each web object by html tag. The product's GUI does change with each release and even between builds. Separating the html tag identifiers (level 3) from the data level (level 2) from the navigation (level 1) helps with these changes in that it is easy to know which file and class needs changing. Additions are also easily made to the correct file, so entropy does not creep in, maintenance does not suffer. By incorporating the test automation tool into the product build process, the goal is to determine when the product is ready to hand over to the QA dept. Time will tell if this simple approach can keep up with a commercial software product lifecycle. - Posted via Jive Forums http://forums.openqa.org/thread.jspa?threadID=4936messageID=13721#13721 ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
