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

Move api/ingest tests to mocha #8106

Closed
wants to merge 13 commits into from
Closed

Conversation

spalger
Copy link
Contributor

@spalger spalger commented Aug 26, 2016

Builds on top of #8101

The api/ingest tests were written to use intern, which we use for functional testing. Overtime these tests have fallen out of sync with the rest of the code because of this, and in an effort to get rid of all the require() statements possible I figured it might be a good time to move these tests over with the rest of the server tests.

Relevant work is in a095119

@spalger spalger force-pushed the apiTestsToMocha branch 3 times, most recently from 94950b7 to a095119 Compare August 29, 2016 22:49
@Bargs
Copy link
Contributor

Bargs commented Aug 30, 2016

I'm not sure how I feel about mixing these tests in with the regular unit tests. It could be really confusing if we want to add legitimate unit tests for any of the route code. It also means that every plugin has to come up with its own server initialization and scenario management infrastructure. I've been thinking for awhile that these tests could stay under /test/unit or maybe something like /test/api and we could simply rewrite them to use mocha instead of the intern. Thoughts? Are there advantages to placing these tests under the Kibana plugin that I'm missing?

@spalger
Copy link
Contributor Author

spalger commented Aug 30, 2016

It could be really confusing if we want to add legitimate unit tests for any of the route code.

In my opinion the mocha tests are not unit tests. They have unit tests, and integration tests, and all sorts of other tests that fall somewhere in a grey area, and I think the only time that confuses people is when they're trying to label them as a specific type of test. I just see it as mocha running function that make assertions about the system.

I've been thinking for awhile that these tests could stay under /test/unit or maybe something like /test/api and we could simply rewrite them to use mocha instead of the intern. Thoughts? Are there advantages to placing these tests under the Kibana plugin that I'm missing?

I don't see any reason to put the tests at the root of the repo. I think that putting the tests near the code:

  • helps people find the tests
  • indicates which parts of the code might have tests
  • gives an indications where new tests should go
  • is the same pattern we have followed for all non-functional tests

@rashidkpc
Copy link
Contributor

I assume all the linting changes were included in error?

@Bargs
Copy link
Contributor

Bargs commented Aug 30, 2016

They have unit tests, and integration tests, and all sorts of other tests that fall somewhere in a grey area, and I think the only time that confuses people is when they're trying to label them as a specific type of test.

Yes, exactly. I (and I think others) find our existing test setup confusing. I should be able to run individual unit test suites quickly and easily from the command line or my editor. But looking at any given tests directory, I can't easily tell if these tests are isolated or if they require a running kibana and/or elasticsearch server. I would bet that unit and integration tests are sometimes even mixed in the same files, because there's no separation. It doesn't matter as much on CI where we just run everything, but mixing things together makes development more difficult. It would also make it almost impossible if we ever want to run unit and integration tests separately on Jenkins.

@spalger
Copy link
Contributor Author

spalger commented Aug 30, 2016

I should be able to run individual unit test suites quickly and easily from the command line or my editor.

I totally agree, and my personal opinion is that there aren't any tests in kibana that are easier to run from the command line than the server tests in mocha:

image

But looking at any given tests directory, I can't easily tell if these tests are isolated or if they require a running kibana and/or elasticsearch server.

Also agree, though this PR is not intending or claiming to solve that problem and definitely doesn't make it any worse. If anything, the fact that the code now has setup and teardown functions describing the fact that it starts the kibana server improve the ability for people to identify the dependencies of these tests. We could take it further, but I think we should discuss how we do that in a new issue and pr.

@Bargs
Copy link
Contributor

Bargs commented Aug 30, 2016

@spalger so I thought about it some more after our Zoom and I'm ok with this setup for now, it's a dramatic improvement over being tied to the intern so I don't wanna get too hung up on other issues.

I do like the idea of solving the isolation problem by providing our tests with a util that each test file can call out to if it needs an ES or Kibana server, and sort of memoizing it so if multiple tests need the same setup they can share the instance in a single run. I'll create a ticket for this.

spalger added 13 commits August 30, 2016 16:56
this became auto-fixable in eslint v3, it was previously applied to only part of the code base
this became auto-fixable in eslint v3, it was previously fixed manually in part of the code base
this rule was added to the shared eslint config[1] and was automatically fixed

[1]: https://github.com/elastic/eslint-config-kibana
this became auto-fixable in eslint v3
this was added to the shared eslint config[1] a while ago and is not autofixable. Instead, a collection of custom jscodeshift transforms[2] were used to fix certain violation formats, and the rest was fixed manually.

[1]: https://github.com/elastic/eslint-config-kibana
[2]: https://github.com/kreeware/kibana-jscodeshift/tree/master/transforms
The import statements produced by jscodeshift do not put spaces between the properties and the curly-braces used in destructuring import statements. This is different from the style they are usually written in, so I enabled this rule to fix them and ensure we keep with the current style.
Several of the timer stubs created a reference to a clock variable, but never used that variable, so they were causing no-unused-vars errors. In the process of fixing those errors, some of those must have been removed, which caused some test failures.
When the tests for the api were written, they ended up using intern. This is not desirable for a number of reasons, but in an effort to remove all remaining `require()` calls I decided to give this migration a shot. Moving the tests to mocha was actually trivial.
@epixa
Copy link
Contributor

epixa commented Oct 8, 2016

@spalger What's your plan here?

@spalger
Copy link
Contributor Author

spalger commented Oct 11, 2016

This still relies on #8101, I plan to merge this once that is in

@spalger
Copy link
Contributor Author

spalger commented Dec 13, 2016

Will be resubmitting this separately.

@spalger spalger closed this Dec 13, 2016
@spalger spalger deleted the apiTestsToMocha branch December 13, 2016 18:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants