[Koha-bugs] [Bug 13691] Add some selenium scripts

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13691

koha at akafred.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |koha at akafred.com

--- Comment #7 from koha at akafred.com ---

I have a feeling that Koha could benefit from having a few tests that exercise
the most critical functionality from a user perspective, both as tools to
measure performance changes and to automate test of critical user scenarios.

These tests should optimally be in the same repo and be versioned along with
the Koha code. That way developers could get rapid feedback on the changes they
make, and also we would require the tests to pass along with production code
changes. 

However, if this turns out to be to much work for the individual developer,
these tests can be in a separate repo and perhaps be maintained by a separate
team – as they in theory not break unless we are changing existing user
functionality. In reality, however, they will from time to time break from
changes the users cannot see, and they will have a certain cost to maintain. 

They will also need installations of Koha running the versions to test against.
My feeling is that one could spend a little effort setting up an infrastructure
for this and do some experiments on how this works, with a small number of
scenarios. 

(Oslo Public Library has some experience in using automated browser based
testing on Koha, using Cucumber and step definitions in Ruby.)

A couple of comments:

*** Browser-based testing ***

This is about testing a running web application:

Examples of tools: 

* Mechanize: (which already is used a little)
- simple 
- only parses html (it has no understanding of JavaScript, which Koha uses more
and more)

* Webdriver (in Selenium 2): (which is what Jonathan has created a patch for)
- drives actual browsers with JavaScript and all (can be "headless" browser)
- you can programatically interact with visible elements like a user
- there is currently no *direct* binding in perl, you have to run "selenium
server" (which needs java) which in turn drives the browsers (in ruby you do
not need this intermediary server) 
https://github.com/gempesaw/Selenium-Remote-Driver/issues/189

*** Feature based testing / behaviour driven testing / example driven testing
***

This is about how your test looks, and in addition to using normal unit test
tools, there are tools like Fit/-nesse and Cucumber that lets you write
automated tests in a way that is easier for users to understand. (Olli-Antti
touched on this.) These tests may or may not be browser-based, but in a
web-based application it is more likely that they do than that they don't. 

*** Acceptance tests ***

These are typically tests for a user story / scenario and confirms that a piece
of functionality is in place and works. They may be expressed in a tool that is
feature-based like the ones mentioned above, and will often drive a browser
interface in a web application like Koha.

-- 
You are receiving this mail because:
You are watching all bug changes.