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

Mocks for CoreStart, CoreSetup and PluginInitializerContext #39351

Merged
merged 18 commits into from
Jun 28, 2019

Conversation

rudolf
Copy link
Contributor

@rudolf rudolf commented Jun 20, 2019

Summary

Mocks for CoreStart, CoreSetup and PluginInitializerContext to make it easier to write plugin tests that depend on Core.

@rudolf rudolf added Feature:New Platform Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc labels Jun 20, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform

@rudolf
Copy link
Contributor Author

rudolf commented Jun 20, 2019

Closes #38679

@elasticmachine
Copy link
Contributor

💔 Build Failed

@rudolf rudolf force-pushed the core-setup-start-mocks branch from e970b27 to a9e37e6 Compare June 21, 2019 12:16
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@rudolf rudolf marked this pull request as ready for review June 21, 2019 19:13
@rudolf rudolf requested a review from a team as a code owner June 21, 2019 19:13
@rudolf
Copy link
Contributor Author

rudolf commented Jun 21, 2019

@stacey-gammon I tested the mocks by using them in the embeddable tests, please review.

@rudolf rudolf requested a review from stacey-gammon June 21, 2019 19:14
@rudolf rudolf added the release_note:skip Skip the PR/issue when compiling release notes label Jun 21, 2019
@rudolf rudolf force-pushed the core-setup-start-mocks branch from 498ca3d to 0d5fadf Compare June 24, 2019 08:46
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@stacey-gammon stacey-gammon left a comment

Choose a reason for hiding this comment

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

Couple questions but generally, LGTM. did not pull down and test locally, code review only.

prod: false,
},
},
config: pluginInitializerContextConfigMock(config)() as jest.Mocked<
Copy link
Contributor

Choose a reason for hiding this comment

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

Just curious, since the only place this is called is right here and the return value is used right away, why not just make it

export function createPluginInitializerContextConfigMock<T>(config: T) {
     const mock: jest.Mocked<PluginInitializerContext<T>['config']> = {
      create: jest.fn().mockReturnValue(of(config)),
      createIfExists: jest.fn().mockReturnValue(of(config)),
    };

     return mock;
}

But I notice you export that file so maybe you assume it will likely be used elsewhere, and in those cases, passed in a value parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, I based this on the tests in https://github.com/toddself/kibana/blob/proxy/x-pack/plugins/proxy/server/cluster_doc.test.ts#L23-L59 (not yet merged into master), which used default and then specific overrides for each of the tests.

Though looking at this again, it feels like this is easy enough for the specific test to implement themselves if they need it. It makes the mock a little weird to consume and developers will probably need to look at the source code to understand the signature, at which point having an additional Object.assign({}, mydefaults, value) is probably much easier to follow for anyone reading the code.

@@ -17,33 +17,15 @@
* under the License.
*/

import { fatalErrorsServiceMock, notificationServiceMock } from '../../../../core/public/mocks';
import { coreMock } from '../../../../core/public/mocks';
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about having this file also be in NP so we don't even have to duplicate this everywhere? Then in your actual test files, you'd just import something like

import { coreMock } from '../../../../core/public/np_core.test.mocks';?

... though I suppose in this case I wouldn't want to mock the overlay functions for everyone... But it does seem like in most cases, just importing the single file is enough for folks who don't have to mock anything particular. 🤔 Just a thought!

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@lizozom
Copy link
Contributor

lizozom commented Jun 26, 2019

FYI Just tried this out in one of my PRs, and it worked great.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@rudolf
Copy link
Contributor Author

rudolf commented Jun 27, 2019

retest

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

LGTM

@rudolf
Copy link
Contributor Author

rudolf commented Jun 27, 2019

retest

@elasticmachine
Copy link
Contributor

💔 Build Failed

@rudolf
Copy link
Contributor Author

rudolf commented Jun 28, 2019

retest

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@rudolf rudolf merged commit da09a11 into elastic:master Jun 28, 2019
@rudolf rudolf deleted the core-setup-start-mocks branch June 28, 2019 11:34
rudolf added a commit to rudolf/kibana that referenced this pull request Jul 1, 2019
…39351)

* Mocks for CoreStart, CoreSetup and PluginInitializerContext

* Public CoreStart, CoreSetup mocks

* Update api signature/docs

* Convert embaddable_api tests to new core mocks

* CR Feedback

* Introduce ui_new_platform.test.mocks and refactor embedabble tests

* Hack to get TS warnings for Core mocks

* Core mocks types cleanup & hack to get TS warnings for Server Core mocks

* Use __mocks__ new_platform

* Remove accidently commited auto-mock

* Introduce MockedKeys type for Core mocks

* Better typing/docs for UiSettings

* Revert "Use __mocks__ new_platform"

This reverts commit 2d666fa.

* Add missing mock to test

* Cleanup UiSettings types
rudolf added a commit that referenced this pull request Jul 1, 2019
…39894)

* Mocks for CoreStart, CoreSetup and PluginInitializerContext

* Public CoreStart, CoreSetup mocks

* Update api signature/docs

* Convert embaddable_api tests to new core mocks

* CR Feedback

* Introduce ui_new_platform.test.mocks and refactor embedabble tests

* Hack to get TS warnings for Core mocks

* Core mocks types cleanup & hack to get TS warnings for Server Core mocks

* Use __mocks__ new_platform

* Remove accidently commited auto-mock

* Introduce MockedKeys type for Core mocks

* Better typing/docs for UiSettings

* Revert "Use __mocks__ new_platform"

This reverts commit 2d666fa.

* Add missing mock to test

* Cleanup UiSettings types
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.3.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants