Good questions. Most likely, we will be loose coupling with Selenium and will shift to our own Engine gradually. The Engine project leverages the power of jQuery for browser encapsulation, searching, action, and event handling. With jQuery, the code would be much clearer and we can focus more on the logic we really want to work on. Another advantage of jQuery is that it is light-weighted but very powerful.
Right now, we are using jQuery 1.3.2, which should have already included the Sizzle Engine. Mikhail, please correct me if I am wrong. jQuery is still only a tool we use for the Engine project. We may still keep both XPath and jQuery selectors for some time until we are confident to shift to jQuery selector completely. The impact on users will be very small because the UI modules are agnostic to the locator strategy we choose. The real advantages of the Engine project are to exploit the UI modules at the Engine side so that we can do UI module caching and group locating on the Engine side to increase robust and remove some dynamic facts. For example, we can have 80% matching for the UI module and it might still be valid. In this way, we can filter out a lot of uncertainties or dynamic factors, which are runtime behavior and would be very difficult to implement in Tellurium core. Another motivation behind this move is to support Tellurium Widgets better. Right now, the Tellurium Widget is not very efficient due to the round trip to the Selenium core. If we can interact with the DOM at runtime, maybe we can improve our current Widget architecture and make it much easier to define and use. Some ideas are still blur to me, but they should become clearer when we move forward. For users, we still have the same DslContext and make the changes encapsulated inside Tellurium core. In the meanwhile, we will still keep the option for you to continue using Selenium core if you want to. I do consider HtmlUnit and seems it is really good for headless testing. However, I am not quite sure if it is as powerful as Selenium. Haven't considered WebDriver yet. Here is the important question we need to ask ourselves: "Do we want Tellurium to be a general framework to wrap up other web testing tools, or we want it to be a specific tool and have its own features". Since existing testing frameworks such as Selenium do not support UI modules, most likely we need to choose the latter path so that we can exploit the UI module better. Thanks, Jian On Mon, Jun 1, 2009 at 1:31 PM, dominicm <[email protected]> wrote: > > Hi all, > > Further to one of Jian's posts in the "Project website status thread", > I'm intrigued by the future relationship of Tellurium and Selenium. > > > "The new Engine would include the following main features > > 1) Use jQuery heavily to re-implement Selenium APIs > 2) Cache UI module on server side and reuse the found elements > 3) Command Bundles > 4) Provide new APIs " > > > This all looks fantastic, but does this mean the project will be more > loosely or more closely coupled to Selenium? If so how would this > affect the integration of other tools (WebDriver, HtmlUnit etc.), > which I would think is desirable if we are looking not to be bound to > any single other project? Presumably we'll be more jQuery dependant, > so will this hinder any such efforts? > > Big questions to busy people, but I'd like to understand a little more > about the directions for the future. > > On another point our dev guys have been looking at Sizzle, which is a > new search engine for jQuery. Maybe this could provide some additional > perf benefits? Apparently it doesn't use XPath at all. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "tellurium-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tellurium-users?hl=en -~----------~----~----~----~------~----~------~--~---
