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

Create tests for savedobject.js in prep of refactoring and changes #9127

Merged
merged 3 commits into from
Nov 28, 2016

Conversation

stacey-gammon
Copy link
Contributor

No description provided.

Copy link
Contributor

@cjcenizal cjcenizal left a 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; }));
Copy link
Contributor

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));

Copy link
Contributor Author

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;
}
Copy link
Contributor

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.

Copy link
Contributor Author

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 () {
Copy link
Contributor

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:

  1. If id is provided, it's available as an id property on the savedObject instance.
  2. If it's 0, it's interpreted as undefined.
  3. If it's false, it's interpreted as undefined.
  4. If it's null, it's interpreted as undefined.
  5. 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.

Copy link
Contributor Author

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 () {
Copy link
Contributor

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', () => {
  });
});

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

});
});
});
});
Copy link
Contributor

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?

Copy link
Contributor Author

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 () {
Copy link
Contributor

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.

Copy link
Contributor Author

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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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);
}));

Copy link
Contributor Author

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);
Copy link
Contributor

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);

Copy link
Contributor Author

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();
Copy link
Contributor

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

Copy link
Contributor Author

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!

@kobelb
Copy link
Contributor

kobelb commented Nov 22, 2016

LGTM!!!

@stacey-gammon stacey-gammon merged commit 469a211 into elastic:master Nov 28, 2016
elastic-jasper added a commit that referenced this pull request Nov 28, 2016
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
stacey-gammon pushed a commit that referenced this pull request Nov 28, 2016
…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
@stacey-gammon stacey-gammon deleted the saved_object_tests branch December 19, 2016 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants