Skip to content
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

Simplify status caching #366

Merged
merged 1 commit into from
Feb 26, 2017

Conversation

mykola-mokhnach
Copy link
Contributor

This PR allows to get rid of unnecessary flag in XCUITestDriver class and make /status response caching more reliable. The PR depends on appium/appium-base-driver#105

@imurchie
Copy link
Contributor

This looks good to me. The version of appium-base-driver needs to be set as at least 2.3.0 so the this.wda.jwproxy.getActiveRequestsCount won't error out, and it would be nice to have some tests on this, to prove it works. A unit test to make sure that the second time through a status request there is no proxy call, perhaps, and a functional test to show that in the middle of a request, a status request still returns straight away (easiest way would be to set the implicit wait high, then try to find a non-existent element without awaiting it. Then the status request ought to return even though the find element request is still being processed).

@mykola-mokhnach
Copy link
Contributor Author

mykola-mokhnach commented Feb 21, 2017

@imurchie where it would be better to put this test (into which file/suite)? Are there some useful examples of similar tests?

beforeEach(() => {
d = new XCUITestDriver();
sandbox = sinon.sandbox.create();
jwproxyCommandSpy = sandbox.stub(d.wda.jwproxy, "command", async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this run? At this point d.wda is unintialized, I think. You probably need something like

d.wda = new WebDriverAgent({major: 8, minor: 2}, {});
d.wda.setupProxy(42);


let result;
B.Promise.any(
[new B(driver.elementsByClassName)('WrongLocator'), new B(driver.status)()]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for creating new promises. Without await both driver.elementsByClassName() and driver.status() return promises already.Also, does B.any(no need for the Promise) guarantee that the first element in the array is called first? I can't find anything indicating that. If it does not, then sometimes this would not test what it is supposed to test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed. Yep, this algorithm won't work as expected

@mykola-mokhnach mykola-mokhnach force-pushed the simplify_status_caching branch 3 times, most recently from 840392a to d25f7f3 Compare February 23, 2017 07:40
lib/utils.js Outdated
@@ -117,6 +120,27 @@ async function checkAppPresent (app) {
log.debug('App is present');
}

async function getGitRev () {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function will not do what you want it to, I don't think. It will, if it returns anything, return the containing project (i.e., run through the full Appium project, it will give the get revision for the Appium project, not the driver).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll exclude this data then

proxySpy.calledOnce.should.be.true;
proxySpy.firstCall.args[0].should.eql('/status');
proxySpy.firstCall.args[1].should.eql('GET');
describe('status caching', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test fails (https://travis-ci.org/appium/appium-xcuitest-driver/jobs/204494918#L2438). Do you not run the pre-commit hooks before committing? This should have been caught there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes time to run this stuff on local machine. I usually test it once and then rely on Travis output while fixing it. Although this one took quite a lot of time for Travis to finish the execution :(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, Travis has been overloaded of late. But the unit tests and eslint ought to be quick, and catch much.

Copy link
Member

@jlipps jlipps left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code changes LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants