Community
Participate
Working Groups
Build Identifier: This is a bug to explore and devise a strategy for some web UI testing. Will begin by reviewing Selenium and learning from sanity testing on another product. Reproducible: Always
Is this bug about testing orion itself or is it about how to support testing while using Orion? The two issues are somewhat intertwined since development of the client is most often done using Orion. But in the first we can be prescriptive about how testing should be done and in the second, we will need to react to what the most common/popular frameworks are out there.
Testing Orion itself - though I suppose you're right - whatever we do in testing our web ui can serve as an example for others testing while using Orion to build their own new web ui apps. My experience with this so far is that automated graphical testing has been expensive to maintain. I'm going to learn from a friend on another team who has done some work in this area to see what he recommends, while I also learn about the testing framework. Minimally for this work item, I'm aiming to put a real example in place, and to discuss where we want to go with it from there. There may also be an opportunity to customize some plugins for developing testing code. Don't know yet. Happy to hear other opinions and advice. Just getting the ball rolling.
Adding bug 362805 as dependent on this. A decent start would be to be able to open all pages on all browsers, run some simple scripts to ascertain that everything loaded properly.
Also adding Bug 371439 and Bug 372399 and Bug 372288. Two of these point to commits that provide some significant improvement to the unit test UI view.
fyi, I am playing a bit with Selenium and Orion...more to report after we ship 1.0
Hi. I've been working with a group of people at our company and we've recently had the opportunity to dedicate our time to open source projects. We came across this thread and have some experience with Selenium integration testing. We'd be happy to help contribute if we could get some guidance and guidelines, as we are all new to open source development. It would give us a chance to improve our understanding of Orion and integration testing and hopefully give you a base battery of tests. Please let us know if you do plan on using Selenium or if our concerted efforts could be useful in some other way. Thanks!
Hi, Jason, I do believe we will be using Selenium at some point (especially with folks willing to help!). Right now we are in the process of making some underlying changes to our client code to get rid of library dependencies such as dojo. So I put my explorations on hold since the dom structure of much of our UI is changing underneath...
Will re-ping Susan about this after she's done the Dojo cleanup
I believe Susan hasn't had time yet give the Dojo work. Likely this is moving to 3.0
Jason, if you have cycles to play around with Orion and Selenium, it would be helpful. Our DOM structure for most pages is now pretty settled and flattened with the dijit widgets removed. What we sorely need to start with is some Selenium Web Driver tests that would open the pages and test a fairly broad set of user interactions. Such as... - open navigator - verify the main links in the banner - create a new folder - create a new file in that folder - rename a file etc... We could set you up with a test userid on orion.eclipse.org. Even tests that simply open every page and verify some of the basic/default content would be better than what we have now. As you probably know, the Web Driver API lets you address dom elements in many ways (id, name, selector, XPath, script, etc.). It seemed to me we should go with ID's, but I decided to hold off until we finished our work replacing dijits since the DOM structure was going to change. That work is nearly done, except for a few git pages, and you can tell which ones immediately when you look at the dom tree. We still have places in the UI where id's are not stable (such as editor outliner) but I think I'd start with id and then use other alternatives when needed. I can answer questions and provide guidance right now, though I am pretty tied up with 2.0 deliverables right now. It'd be great to have someone looking at this in parallel. I'd be happy to write some bulleted test scripts of stuff that would be nice to test if that's helpful.
(In reply to comment #10) Hi Susan. It's good to hear from you. I definitely have an interest in pursuing this project further but I no longer personally have the time. I do, however, have co-workers on the bench who are interested in utilizing their experience in Selenium to contribute to Orion. I do have some questions that would clarify how we could begin a UI testing framework. 1. How do you want to run the tests? Will these tests be integrated into your nightly build tests or be a separate suite to run after UI changes? 2. Where would these test cases and page objects (Assuming we follow the Selenium Page Object design pattern) live in the project structure? 3. Should testing focus a remotely hosted instance of Orion, like orionhub or orion.eclipse.org? What would be the difference between that and testing the UI on local instances? My main concern is just making sure that the tests we write can be integrated into Orion with limited hassle. Hope to hear from you soon.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
