-
Notifications
You must be signed in to change notification settings - Fork 73
Changes that add and integrate code coverage support into XDMoD's CI pipeline #1443
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
base: xdmod10.5
Are you sure you want to change the base?
Conversation
browser.setValue(input, setting.updated); | ||
const updatedValue = browser.getValue(input); | ||
expect(updatedValue).to.equal(setting.updated); | ||
for (let i = 0; i < 100; i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will hide test failures if the exception is thrown more than 100 times
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to make multiple attempts then you'll need to (a) add a short pause between tries (e.g. 10ms), and (b) make sure to throw an exception if the max attempts is reached.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've ended up removing these for
loops as the ended up being unnecessary with the latest updates.
browser.click(inputTrigger); | ||
setTimeout(function () { | ||
browser.click(inputTrigger); | ||
}, 3000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
three seconds seems like a long time to wait here. Why was it increased so much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and the previous waitForVisible
could also be combined into a waitAndClick
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've actually ended up removing the setTimeout
calls and everything still seems to be passing both w/ and w/ out XDebug.
180516d
to
02428b3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of me wants to do a completely separate PR just for all the test updates...But at the same time the reason they were done is because of the timing issues with xdebug enabled.
I am so conflicted...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good as long as it still passes shippable (cause travis is the broken at the moment)
6f42a7b
to
db77bb7
Compare
c5ba815
to
2ff4108
Compare
- Added four new scripts responsible for installing & configuring XDebug, generating the code coverage data from php file execution, and generating the final reports. - Updated `shippable.yml` so that XDebug / Code Coverage is only generated during the nightly test build. - Updated numerous UI tests to work more reliably when XDebug is installed ( i.e. their timeouts were increased ) - Updated a couple of UI test selectors to minimize the effects of latency on particular tests. - Added a new webdriverhelper function called `clickSelectorAndWaitForMask` as this was a commonly feature during developing this PR. - Updated the timeout for a few other webdriverhelper functions.
- It was found while running these tests on the CentOS8 image, that the `setupBeforeClass` function was not being called as expected, this small addition will catch if the required `self::$hashFilePath` variable has been set, and if not then run the `setupBeforeClass` function so that it is populated.
- Since we're now running this script on CentOS7|8 and Rocky8.5 containers we need to take into account the different software versions / configuration options that must be set to successfully collect the code coverage data generated by our tests.
By installing Xdebug and setting up code coverage before running bootstrap we'll generate code coverage information for our install / upgrade code including the ETL code.
120462f
to
dcaac39
Compare
I force triggered the code coverage generation in the last commit to make sure that it works. Before I set it back I just wanted to document the code coverage artifacts from each build:
|
NOTE: this PR takes the place of #1350
All of the functional changes are the work of Zi-3 all that I've (@ryanrath) done is clean things up a little.
Description
generating the code coverage data from php file execution, and generating the final
reports.
shippable.yml
so that XDebug is installed / Code Coverage is only generated during the nightlytest build.
clickSelectorAndWaitForMask
as this was needed for a test or two.Motivation and Context
Adding code coverage will allow us to get a general sense of where we are lacking test code & possibly where we have unused code thus giving us a few more tools to help streamline / increase the reliability of XDMoD.
Tests performed
All the automated tests for an install / upgrade with & without XDebug installed.
Checklist: