Student Project

[Simon Mulser]

Hello,

we are a group of students studying software engineering at the TU Vienna. for our master degree we do a course called software architecture where we have to analyse an open source program and yes we have chosen selenium :) so far we have read some articles and had a closer look to the Java, Python and .Net bindings and also to the firefox driver (plugin), but as you can guess it is very hard for us to dive in a so big code base with so many different languages. as outcome we should have component & connector view (http://en.wikipedia.org/wiki/Component_diagram) and one other complementary architecture view which we can choose free. in addition we should describe two qualities (non functional properties) of selenium. 

for the qualities we have chosen usability and modifiability and we have found the following tactics to ensure these qualities.

usability:

• providing language bindings in many languages (facilitated with thin language bindings, a uniform rest-ish communication protocol, ...)
• verbose and easy to use language bindings (class by, ...)
• helpers for known patterns (pagefactory, ...)

modifiability:

• thin language bindings
• atoms

for these research we have mainly used these links:

https://code.google.com/p/selenium/

http://www.seleniumhq.org/
http://www.aosabook.org/en/selenium.html

our questions would be:
do you have other good resources which we should read? can you give as other tips for tactics which facilitates the qualities usability and modifiability? do you have some architectural views of selenium? any other suggestions?

of course we would like to share our outcome after the course with you and we hope we can provide you something useful for this awesome project!

cheers, simon

[Daniel Wagner-Hall]

Hi Simon,

It sounds like you have an interesting project! A few thoughts in-line:

On 17 November 2014 at 18:40, Simon Mulser <simon...@gmail.com> wrote:

Hello,

we are a group of students studying software engineering at the TU Vienna. for our master degree we do a course called software architecture where we have to analyse an open source program and yes we have chosen selenium :) so far we have read some articles and had a closer look to the Java, Python and .Net bindings and also to the firefox driver (plugin), but as you can guess it is very hard for us to dive in a so big code base with so many different languages. as outcome we should have component & connector view (http://en.wikipedia.org/wiki/Component_diagram) and one other complementary architecture view which we can choose free. in addition we should describe two qualities (non functional properties) of selenium. 

for the qualities we have chosen usability and modifiability and we have found the following tactics to ensure these qualities.

usability:

• providing language bindings in many languages (facilitated with thin language bindings, a uniform rest-ish communication protocol, ...)
• verbose and easy to use language bindings (class by, ...)
• helpers for known patterns (pagefactory, ...)

modifiability:

• thin language bindings
• atoms

for these research we have mainly used these links:

https://code.google.com/p/selenium/

http://www.seleniumhq.org/
http://www.aosabook.org/en/selenium.html

our questions would be:
do you have other good resources which we should read?

http://www.aosabook.org/en/selenium.html has a lot of interesting commentary which you may find useful.

can you give as other tips for tactics which facilitates the qualities usability and modifiability?

A few other things that hopefully help usability:

 * Concise, fluent APIs - if you have an object, and you press Ctrl+Space in your IDE, you hopefully have few enough methods that you can read the list, and they're hopefully named clearly enough to work out roughly what you should be using.

 * Possibly slightly off-topic, but exception detail. WebDriverExceptions report in their error message, among other things, the OS you're on, the version of the OS you're on, and other useful data. This means that when a user pastes an exception into an email asking for help, most of the information we need to help is hopefully there, rather than requiring users also report it (which people are notoriously bad at doing).

 * Consistent API and implementation across different browsers. We try pretty hard to paper over browser-specific quirks, and offer the same API across each of them. A simple example of this is WebElement#getText() - there is, it turns out, no standard for getting the visible text of an element - both innerText and textContent are ill-specified and inconsistent across browsers, so we have a consistent algorithm across all of them. Another example is that CSS colours are nomalised into one consistent format, covering up where one browser may report a colour as #000000, another as #000, another as rgb(0, 0, 0), and yet another as 'black'.

 * Not making promises we can't keep [note that some people consider this a usability flaw]. It is not possible, for instance, to tell for absolute certain when a page has finished loading. (e.g. if it has a timer running in the background updating a stock price every 30 seconds, has the page ever truly loaded? What if it has an AJAX call pending? What if you have an infinite scroll page, which always has more content to load?). So Selenium doesn't try to guess - it says bluntly that you need to provide your own synchronisation. This on the face of it may sound inconvenient, but it means that when something in the browser, or Selenium changes, there are no implicit promises which may be violated. If you're forced to do the right thing from the beginning, you won't be surprised when we stop happening to do it for you.

And a few other things which hopefully help modifiability:

 * Cross-language build system. While the build system may appear daunting at first, once you get your head around it, it's pretty simple and clear. In particular, though, the fact that there is one build system for each language, and you can have cross-language dependencies easily, means that hopefully when you come to modify things, it's one fewer barrier.

 * In-browser development. The atoms' test suite runs in-browser, which means that you can test changes by editing the source and refreshing your browser window. This is a lot nicer than having to run unit tests (or worse, integration tests) from the command line.

 * Continuous integration. If you don't have a Windows machine of your own, we have systems which run the tests in IE for you [big shout out to Sauce Labs for providing a lot of the backend for this]. This lowers the barrier to entry in order to contribute.

do you have some architectural views of selenium? any other suggestions?

of course we would like to share our outcome after the course with you and we hope we can provide you something useful for this awesome project!

cheers, simon

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/6b5680c9-0312-4019-b02a-0d202548e251%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Mulser]

Sorry for my late reply. You can find our outcome in the attachment. It could be maybe useful to improve your documentation or to onboard new developers. If you have any question don't hesitate to contact me.

Cheers,

Simon