-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Create tests for savedobject.js in prep of refactoring and changes #9127
Create tests for savedobject.js in prep of refactoring and changes #9127
Conversation
175fc03
to
a6fd8f0
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.
Looks great! I have some suggestions but I'll leave it up to you to decide to implement or not.
let stubbedMapper = Private(MapperService); | ||
|
||
sinon.stub(stubbedMapper, 'getFieldsForIndexPattern', function () { | ||
return Promise.resolve(mockLogstashFields.filter((field) => { return field.scripted === false; })); |
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 can be slightly simplified:
return Promise.resolve(mockLogstashFields.filter(field => field.scripted === false));
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.
Nice! & done.
let savedObject = {}; | ||
savedObjectFactory.call(savedObject, config); | ||
return savedObject; | ||
} |
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.
Minor nit: can we move these functions above the beforeEach
? That way all of the "helper" vars and functions are defined before the mocha-specific beforeEach
and define
calls.
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.
indeed, done!
}); | ||
}); | ||
|
||
it('applied to source if an id is given', function () { |
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.
Can we add a few more assertions:
- If
id
is provided, it's available as anid
property on thesavedObject
instance. - If it's
0
, it's interpreted asundefined
. - If it's
false
, it's interpreted asundefined
. - If it's
null
, it's interpreted asundefined
. - If it's not provided, it defaults to
undefined
.
I'm just thinking we should document this (kinda odd) behavior in case anything depends on it.
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.
done
}); | ||
}); | ||
|
||
it('searchSource creates index when true', function () { |
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.
Can we create an assertion for when it's false?
describe('searchSource', () => {
describe('when true, blah blah', () => {
});
describe('when false, blah blah', () => {
});
});
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.
done
}); | ||
}); | ||
}); | ||
}); |
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.
Might also be good to add tests for other instance methods applyESResp
, serialize
, save
, saveSource
, destroy
, and delete
. What do you think?
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.
Added one for applyESResp. Save I'd prefer to get in the save/rename flow since I know what to test there. As for the others, it feels like I'd just be testing implementation details as opposed to expected results, so at least with my current understanding of this code, it doesn't seem super beneficial. (e.g. for delete, I could test that es.delete is called, but not that the item is actually deleted).
import { stubMapper } from 'test_utils/stub_mapper'; | ||
import IndexPatternFactory from 'ui/index_patterns/_index_pattern'; | ||
|
||
describe('Saved Object', function () { |
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 relates to #9161, I've seen a number of tests that would've used 'ui/courier/saved_object' for the describe
, but I've also seen a number of tests do it this way. I'm not sure which way is preferred.
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 don't know if there is a rule for this, but I think I prefer not specifying the path, otherwise you'd have to update the test if you move the file and I could see that easily being forgotten.
let esStub; | ||
|
||
beforeEach(ngMock.module('kibana')); | ||
beforeEach(ngMock.inject(function ($injector, Private) { |
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.
Is there a reason we're injecting $injector
and then using $injector.get('es')
below as opposed to just injecting es
?
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.
fetch.js does something similar to what I did, getting es from the injector. Happy to write it another way that makes more sense but I'm not sure how to 'just inject es'. If you can give me a little code snippet to explain your suggestion I can add it.
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 you could change this to the following:
beforeEach(ngMock.inject(function (es, Private) {
SavedObject = Private(SavedObjectFactory);
IndexPattern = Private(IndexPatternFactory);
esStub = es;
mockEsService();
stubMapper(Private);
}));
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.
ah, awesome, done!
|
||
beforeEach(ngMock.module('kibana')); | ||
beforeEach(ngMock.inject(function ($injector, Private) { | ||
savedObjectFactory = Private(SavedObjectFactory); |
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 feel like I've more commonly seen this being imported as SavedObject
and then used as a constructor in the createSavedObject
below.
So instead of having:
let savedObject = {};
savedObjectFactory.call(savedObject, config);
return savedObject;
it'd become:
return new SavedObject(config);
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.
Ah, much better. I was confused with the factory and private stuff, making this overly complicated. Done!
describe ('config', function () { | ||
|
||
it('afterESResp is called', function () { | ||
let afterESRespCallback = sinon.spy(); |
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.
Throughout the tests, there's an inconsistent usage of const
and let
. There appears to be a pattern that generally let
is used when an object will be 'mutated'; however, that's not the difference between const
/let
in javascript. let
allows a reference to be reassigned per https://github.com/airbnb/javascript#references--prefer-const
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.
Learn something new every day. Changed to const!
LGTM!!! |
Backports PR #9127 **Commit 1:** Create tests for savedobject.js in prep of refactoring and changes * Original sha: a6fd8f0 * Authored by Stacey Gammon <[email protected]> on 2016-11-17T17:06:59Z **Commit 2:** Address code review comments * Original sha: fce433d * Authored by Stacey Gammon <[email protected]> on 2016-11-22T19:19:20Z **Commit 3:** Remove needless injector param, replace with es * Original sha: 834cb27 * Authored by Stacey Gammon <[email protected]> on 2016-11-22T19:43:06Z
…9232) Backports PR #9127 **Commit 1:** Create tests for savedobject.js in prep of refactoring and changes * Original sha: a6fd8f0 * Authored by Stacey Gammon <[email protected]> on 2016-11-17T17:06:59Z **Commit 2:** Address code review comments * Original sha: fce433d * Authored by Stacey Gammon <[email protected]> on 2016-11-22T19:19:20Z **Commit 3:** Remove needless injector param, replace with es * Original sha: 834cb27 * Authored by Stacey Gammon <[email protected]> on 2016-11-22T19:43:06Z
No description provided.