Tools mailing list archives
tools@odoo-community.org
Browse archives
Qunit test
by
Anybox, Pierre Verkest
Hi!
I hope I'm using the good mailing list?!to launch Odoo QUnit[1] tests from a **python** command line
on multiple browsers for CI using selenium webdrivers
(could be local browsers, using selenium grid,
cloud provider like sauceLabs, ...).
Why I'm doing that:
* I'm writing QUnit tests and I'm lazy to open 2 browsers
* I would like to test on browsers that I haven't installed
on my laptop
* I would like to test on browsers that I haven't installed
on my laptop
* TDD is great
* I would love if this kind of tools motivate developers
to write more of them (Utopian!)
to write more of them (Utopian!)
* This is a fun challenge to myself
At this time it's an early stage and I plan to change things
like naming, documentation... please do not have look of
details but speaking about concepts.
like naming, documentation... please do not have look of
details but speaking about concepts.
What I've done:
I've split the project in 3 parts:
* selenium-odoo-qunit:
is a command line python app to launch odoo qunit tests
to multiple browsers, this is based on anybox-nose-selenium
is a command line python app to launch odoo qunit tests
to multiple browsers, this is based on anybox-nose-selenium
* anybox-nose-selenium:
is a nose plugin that duplicate TestCase instance
per browsers to run same tests over each browsers
is a nose plugin that duplicate TestCase instance
per browsers to run same tests over each browsers
(this works with multiprocessing nose plugin to
run those tests in parallel)
* selenium-extra-api:
that prepare an instance of selenium webdriver per
expected browsers from a config file, which is used
by anybox-nose-selenium
The working POC launch qunit tests from oca/web repo
(8.0 branch) on the lastest local Firefox browser and
on a Selenium grid infrastructure (that is spawned in dockers)
(8.0 branch) on the lastest local Firefox browser and
on a Selenium grid infrastructure (that is spawned in dockers)
which contains two nodes, one with chrome and another with
firefox.
* travis: https://travis-ci.org/petrus-v/web
* web: 8.0-selenium-qunit-test branch
* MQT: selenium-qunit-test branch
What I plan:
* writing documentation of each pieces
* analyze what I've done in selenium-odoo-qunit if it's specificto odoo or could be use on any qunit test (I wonder if
Odoo team has re-create the wheel on this part ?)
* Analyze how to work with cloud provider and what kind of result
could be useful
* Analyze other projects if there are some practices
about selenium capabilities configuration
* rename those 3 packages, yet I'm not sure here some idea:
- selenium-odoo-qunit => selenium-qunit
- selenium-odoo-qunit => selenium-qunit
- anybox-nose-selenium => nose-selenium-multi-browser
- selenium-extra-api => selenium-configurator
- selenium-extra-api => selenium-configurator
* add unittest on selenium-qunit
* Define if it needs some additional reporting to display
compatible browsers (per branch / per modules / ??)
A bit of philosophy
Before to be happy and excited about all of that I would like
to notice you if we are running this kind of tool we will have
to decide a list of supported browsers that OCA modules should
support and how long we want to support them (number of versions
per browsers, what about new versions...)
This is probably an early question but I'm worry about what it'll
implied to the developers. For instance, I'm writing a great web
to notice you if we are running this kind of tool we will have
to decide a list of supported browsers that OCA modules should
support and how long we want to support them (number of versions
per browsers, what about new versions...)
This is probably an early question but I'm worry about what it'll
implied to the developers. For instance, I'm writing a great web
module with Qunit test that I want to share within the OCA
(It's already a recognizable work) and I know my customer is
only running it on chromium. Then I have to do much more effort to
make it works on other browsers that OCA choose as required which I
I don't care about... I wouldn't like this tool demotivate
I don't care about... I wouldn't like this tool demotivate
contributors and make more endless PRs.
On an other hand, OCA is here to add values to the odoo ecosystem
so it would be a shame if we can't decide some required browsers.
While I'm writing those lines it give me some ideas... what we would
probably need is to define some required browsers and test modules
probably need is to define some required browsers and test modules
over more browsers, and report modules that have been passed on which
browsers, this list won't lock for merging but will prevent developers
and challenge them to fix what's wrong to be compatible over a maximum
of them.
I wonder if there are QUnit test coverage tool that we could easily
integrate we would probably scary about the result!... this is not the
integrate we would probably scary about the result!... this is not the
topic, just to tell that if we display a list of modules that are
ready to run on specifics browsers and tests cover only 2% of javascript
code modules are ready only for those 2% that are tested... I was a
ready to run on specifics browsers and tests cover only 2% of javascript
code modules are ready only for those 2% that are tested... I was a
bit disappointed to see that I'm the only one who write QUnit test on
oca/web 8.0 branch.
So my opinion on this self reflection would to start to make it works
and only display warnings or results somehow to developers, then see
how the community is using it and adapted it's behaviors!
Why I'm writing to this mailing list?
I would like to know what you think about, is this will be useful for
the OCA?
Do you know some other existing tools that I probably missed?
Should we spawn grid on travis, maintain an OCA selenium grid,
using local browser within travis or using a cloud provider?
the OCA?
Do you know some other existing tools that I probably missed?
Should we spawn grid on travis, maintain an OCA selenium grid,
using local browser within travis or using a cloud provider?
Regards,
--
Anybox
Pierre Verkest
06 51 35 50 50
Github: petrus-v - Twitter: petrusv84
[1] QUnit: A JavaScript Unit Testing framework.
[1] QUnit: A JavaScript Unit Testing framework.
For instance, the one I'm most proud is this current PR where
an instance of Form View is create to test the widget behaviors
(If you love stories...)
an other one was on this PR, I used to develop on chromium,
in the first implementation of this test, I used .getSelection()
but that was failing on Firefox due an old issue, if we have this kind of
tool we can find out earlier this kind of problems avoiding some frustration!
an other one was on this PR, I used to develop on chromium,
in the first implementation of this test, I used .getSelection()
but that was failing on Firefox due an old issue, if we have this kind of
tool we can find out earlier this kind of problems avoiding some frustration!
Follow-Ups
-
-
-
-
-
Thanks for this great contribu [...]
byOpen Source Integrators, Maxime Chambreuil- 08/01/2016 15:55:00 - 0 -
-
