New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write Installer/Updater screenshot tests #2935
Comments
(In [5866]) refs #2935 - remove broken webtests =P |
(In [5992]) refs #2935 - re-enable JavaScript (hack) |
(In [5993]) refs #2935 - add delay for form to auto-post |
(In [6007]) refs #2935 - simulate auto-post form |
It is really critical for our QA process to re-enable the Webtests on Jenkins. @anthon would you have an estimate for this task? is it half day or 2 days work? :) |
Much more than 2, I suspect -- a lot of web tests were disabled. Moreover, the ticket involves rewriting all the web tests. We would switch to either PHPUnit+Mink or Behat+Mink. Using Mink will give us more driver choices, eg Selenium (or Selenium2) for pages with JavaScript (eg testing software update), and non-Selenium drivers for non-JavaScript pages (eg login). |
(oh another option is phpspec + mink) |
It sounds really hard and might never happen.. :( Maybe we could find a workaround to re-enable at least the install/update tests which were an incredibly useful part of our QA toolset... ? Is there a way to make the existing tests work again using selenium? I remember the problem was about Javascript files/Jquery not being executed properly to click on some buttons? |
the javascript engine used by HtmlUnit couldn't handle the dynamic changes to the DOM. I'm subscribed to the webtest mailing list and we are not the only ones feeling the pain. It might be nice to use Behat+Mink. I've already done work here to parallelize Selenium testing. |
Webtests are not that critically important, compared to getting Jenkins back to working. Decreasing priority... Anthon, do you reckon I should create a ticket for Jenkins setup? |
Many times our sql update code wasn't failure-friendly and would fail when re-executed as it left the DB in a half-updated state. Having the following test would ensure that all future update scripts written are working in a failure scenario. A new idea for a webtest:
|
I've been told we should use Webdriver eg. https://github.com/facebook/php-webdriver and we could run the test on Travis CI as well. If anyone is fluent in webdriver/selenium, please contact me at matt@piwik.org :) |
Consolidating milestones FTW |
In 50742af: Refs #2935, add installation UI test, allow no fixture to be specified for screenshot test and fix following installation process regressions:
|
@capedfuzz well done on adding those tests. Please close the ticket if it's fixed :) |
Feedback:
|
…e specified for screenshot test and fix following installation process regressions: - pending events should be executed after all plugins successfully loaded so plugin order in config file is unimportant - do not set piwikUrl on View instances if the DB cannot be connected to - create Twig instance when clearing template cache instead of new View
The last big missing functionnality not yet tested is our Installation process, as well as the update process.
Let's add screenshot tests for:
The result will be that we always know whether installation + update to latest Piwik work. This will result in more agility and ability to release new versions faster.
The text was updated successfully, but these errors were encountered: