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

tests: re-organize driver tests by method #7212

Merged
merged 5 commits into from
Feb 13, 2019
Merged

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented Feb 11, 2019

tl;dr - for EASIER REVIEWING just look at 8772643

Summary
It's no secret that driver tests have been somewhat of a mess for a long-time. Driver is one of the most critical pieces of Lighthouse logic and yet adding tests has always been intimidating and somewhat unconvincing that things are working. This PR is a first step in an attempt to change that.

The Changes

  • Organizes all the tests by the method. Already much easier to see where we have coverage and where we're lacking.
  • Minor renaming of driverStub -> driver. The driver here is a real driver, its the connection and sendCommand functions that are stubs.
  • Moves to a more readable format where each method stubs the sendCommand methods that it actually uses. This should hopefully make it much easier and less magical for contributors to understand what each method on driver requires, how to add tests that use new protocol methods, etc. A nice side effect is decent documentation about what each protocol method will actually do.

image

Related Issues/PRs
#7174, didn't want to proceed with more major gotoURL without the promised cleanup and testing first

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

still looking, but this is looking great to me. Some feedback on the infrastructure functions

registrationId: id,
scopeURL: url,
};
function findSendCommandInvocation(command) {
Copy link
Member

Choose a reason for hiding this comment

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

some docs here would be good

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

scriptURL: url,
controlledClients,
status,
function createSendCommandMockFn() {
Copy link
Member

Choose a reason for hiding this comment

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

docs would be good here too (e.g. the returned function has a mockSendCommandResponse on it, use it to push responses, can be used multiple times, where each call will get the next one, etc

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

return Promise.resolve(mockResponse);
}

function sendCommandOldStub(command, params) {
Copy link
Member

Choose a reason for hiding this comment

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

keeping this because it'd be too much churn to remove it and break up across tests?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah I had to draw the line somewhere for the first pass. half the tests still need sendCommandOldStub but absolutely the idea is to migrate the rest of them too

name: 'novalue',
}],
result:
params.objectId === 'invalid'
Copy link
Member

Choose a reason for hiding this comment

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

prefer the old formatting :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

reverted

scopeURL: url,
};
function findSendCommandInvocation(command) {
expect(connectionStub.sendCommand).toHaveBeenCalledWith(command, expect.anything());
Copy link
Member

Choose a reason for hiding this comment

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

it's a little weird to me that it's using the assumed global connectionStub here (while createSendCommandMockFn is all encapsulated), could we put this as another method on the return value of createSendCommandMockFn()? Or have the particular sendCommand method passed in

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yeah sounds good to add to the mock function! 👍 done

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

yeah, ❤️ this.

Main feedback is as before, on the ergonomics two sendCommand helper functions and if we can get rid of sendCommandOldStub. It seems like it's only still used in those top tests for querySelector and getObjectProperty? Would be great to get rid of it and the long list of commands it's not clear which one goes to which test :)

@patrickhulce
Copy link
Collaborator Author

Would be great to get rid of it and the long list of commands it's not clear which one goes to which test :)

You cool with following up with this and the rest of the driver cleanup in separate PR?

@patrickhulce
Copy link
Collaborator Author

^^ @brendankenny that one was for you :)

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

You cool with following up with this and the rest of the driver cleanup in separate PR?

SGTM

@patrickhulce patrickhulce merged commit e6dbefa into master Feb 13, 2019
@patrickhulce patrickhulce deleted the driver_test_reorg branch February 13, 2019 21:49
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