Skip to content
This repository has been archived by the owner on Mar 1, 2022. It is now read-only.

Restructured test suites #5

Merged
merged 11 commits into from
Nov 13, 2018
Merged

Restructured test suites #5

merged 11 commits into from
Nov 13, 2018

Conversation

naz
Copy link
Contributor

@naz naz commented Nov 8, 2018

closes #4

  • Removed much of redundant test suites
  • Cleaned up main module api suite

Test suites for mongo-knex and mingo were removed as packages by themselves prove the validity of their code. We just need to know if NQL glues them together properly, which is proved by remaining suites

@naz naz changed the title [WIP] Removed unneeded test suites Removed unneeded test suites Nov 8, 2018
@naz
Copy link
Contributor Author

naz commented Nov 8, 2018

Left the suite only with the basic module api test. The rest is just too specific to what mongo-knex or mingo are supposed to do by themselves.

@kirrg001
Copy link
Contributor

kirrg001 commented Nov 8, 2018

Are the removed tests covered in nql-lang?
https://github.com/NexesJS/NQL/blob/master/test/nql_knex.test.js

@kirrg001
Copy link
Contributor

kirrg001 commented Nov 8, 2018

I think this needs to stay

0ce5ffc

Because mingo is used in NQL. There is no repository.

@naz
Copy link
Contributor Author

naz commented Nov 8, 2018

Are the removed tests covered in nql-lang?

yes, the suite is a lot more extensive there - https://github.com/NexesJS/NQL-Lang/blob/master/test/parser.test.js#L16

I think this needs to stay 0ce5ffc

I was thinking if it should be removed completely, partially or stay as is. But decided to go with full removal because to me it seems like it's just testing if the result produced by nql-lang parser is applicable to json objects. The correctness of ngl-lang output is covered by the modules unit test, the correctness of mingo using query operators is covered by the module itself quite well. In my opinion, the only thing left to cover if ngl 'glues' nql-lang and mingo correctly which is done by api.test.js. @kirrg001 what's your perspective on this?

@kirrg001
Copy link
Contributor

kirrg001 commented Nov 8, 2018

yes, the suite is a lot more extensive there - https://github.com/NexesJS/NQL-Lang/blob/master/test/parser.test.js#L16

Cool. Did you compare both and check for missing cases which were covered in this repo, but not covered in nql-lang?

@kirrg001
Copy link
Contributor

kirrg001 commented Nov 8, 2018

I was thinking if it should be removed completely, partially or stay as is. But decided to go with full removal because to me it seems like it's just testing if the result produced by nql-lang parser is applicable to json objects. The correctness of ngl-lang output is covered by the modules unit test, the correctness of mingo using query operators is covered by the module itself quite well. In my opinion, the only thing left to cover if ngl 'glues' nql-lang and mingo correctly which is done by api.test.js. @kirrg001 what's your perspective on this?

Yeah makes sense.
But we said we want to keep one test per use case or?

filter -> nql -> nql-lang -> mingo
filter -> nql -> nql-lang -> mongo-knex

@naz
Copy link
Contributor Author

naz commented Nov 8, 2018

But we said we want to keep one test per use case or?

We didn't come to final decision, but maybe having just one simple case for mingo and mongo-knex would be good. With a comment that it's just a sanity check if things are guled together correctly and more extended logic is meant to be tested in those modules internally.

filter -> nql -> nql-lang -> mingo
filter -> nql -> nql-lang -> mongo-knex

yes 💯 the path which takes for filter to be transformed into JSON or SQL statement.

@kirrg001
Copy link
Contributor

kirrg001 commented Nov 8, 2018

We didn't come to final decision, but maybe having just one simple case for mingo and mongo-knex would be good. With a comment that it's just a sanity check if things are guled together correctly and more extended logic is meant to be tested in those modules internally.

Yeah. I think we should not remove everything and leave one test per use case in this PR?

@naz
Copy link
Contributor Author

naz commented Nov 8, 2018

Cool. Did you compare both and check for missing cases which were covered in this repo, but not covered in nql-lang?

I didn't check assertion by assertion, but each describe group was covered 100% by nql-lang and looked even more exntensive than what was availalbe in here. Same for mongo-knex, hence
the link in first commit message - https://github.com/NexesJS/mongo-knex/blob/master/test/unit/convertor.test.js 😃

@naz
Copy link
Contributor Author

naz commented Nov 8, 2018

@kirrg001 done the changes discussed above ;)

test/nql_knex.test.js Outdated Show resolved Hide resolved
@naz naz changed the title Removed unneeded test suites Restructured test suites Nov 13, 2018
@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

@kirrg001 last commit is mostly a copy of mongo-knex setup to be able to test this way

@kirrg001
Copy link
Contributor

I'd suggest to ask John tomorrow to enable travis for NQL. Then we can run this PR on travis.

@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

@kirrg001 linting is failing with a ton of errors, do we wanna skip it for now?

@kirrg001
Copy link
Contributor

@kirrg001 linting is failing with a ton of errors, do we wanna skip it for now?

Did you bump eslint plugin to the latest?

@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

Did you bump eslint plugin to the latest?

Nope. Will try it now

kirrg001 added a commit that referenced this pull request Nov 13, 2018
refs #1

- mongo-knex supports some relation cases already
- forward options to mongo-knex
- remove tests which have a wrong assertions
  - these tests are removed in #5 anyway
@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

yarn test passes nicely, it's good to be integrated with Travis now. Also tested MySQL version, it works.

kirrg001 added a commit that referenced this pull request Nov 13, 2018
refs #1

- mongo-knex supports some relation cases already
- forward options to mongo-knex
- remove tests which have a wrong assertions
  - these tests are removed in #5 anyway
kirrg001 added a commit that referenced this pull request Nov 13, 2018
refs #1

- mongo-knex supports some relation cases already
- forward options to mongo-knex
- remove tests which have a wrong assertions
  - these tests are removed in #5 anyway
- this adds the ability to start using relations
- NOTE: relations are not fully supported, only partially
@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

@kirrg001 rebased upon master, lmk if we can 🚢 this

@kirrg001
Copy link
Contributor

@gargol up to you. either we merge it now or tomorrow when travis is enabled 🤘🏽👻

@naz
Copy link
Contributor Author

naz commented Nov 13, 2018

Would do travis as a separate PR. Don't want to deal with rebases too much 😸

@kirrg001
Copy link
Contributor

Yeah 100% separate PR. Just wanted to see if the PR passes. But feel free to merge this already :) Doesn't rly matter

@naz naz merged commit 3fee0da into TryGhost:master Nov 13, 2018
@ErisDS
Copy link
Member

ErisDS commented Nov 27, 2018

We didn't come to final decision, but maybe having just one simple case for mingo and mongo-knex would be good. With a comment that it's just a sanity check if things are guled together correctly and more extended logic is meant to be tested in those modules internally.

I have only just seen this PR, and disagree strongly with the decision made here. Mingo is a 3rd party module that we depend on heavily for functionality not just here in NQL but deep within Ghost.

Now, when a new version of mingo comes along, we have no way to determine if our use cases are still handled correctly. That's the purpose of integration tests.

The tests were already written, and took 146ms to run. What was the reason for suggesting their removal in the first place?

@@ -0,0 +1,31 @@
const Nconf = require('nconf');
Copy link
Member

Choose a reason for hiding this comment

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

If this is purely for testing, surely it should live within the test directory?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point 👍 Was following the structure in mongo-knex. Will change it in both places

@naz
Copy link
Contributor Author

naz commented Nov 27, 2018

Can't find any specific reference point around decision making for this PR except the issue it reference. The idea behind removing test suites from this repo was to leave the testing of implementation to the libraries that this package glues together to those libraries. For example, nql_mingo.test.js suite was removed as it seemed to have tested what mingo itself tests - a compliance with MongoDB query language.
I see the point of not having visibility over whether the version bump is breaking any of our use cases. We could trust that mingo's implementation is following MongoDB query language spec 100%, but that's probably a very bad idea with external dependency we don't have any control over.

@ErisDS
Copy link
Member

ErisDS commented Nov 27, 2018

What I see is, the issue makes a proposal without reasoning. All further discussion has been around details.

I can't see that the tests were getting in the way or causing any problems, so I'm curious about the justification for spending time on removing them?

@naz
Copy link
Contributor Author

naz commented Nov 28, 2018

I think I jumped to fast into a conclusion of removing the test suite and missed it's of it being here in the first place. Also made a mistake of not documenting properly such a decision. Will get the integration suite for mingo back to life. Should the suite for nql_knex.test.js stay removed? As it's well covered in here

@ErisDS
Copy link
Member

ErisDS commented Nov 28, 2018

My point is more that I don't understand why the issue was even raised, not just the conclusion. I don't see any value to having removed any test suites unless they were explicitly causing you problems whilst doing other important work.

Right now, the focus needs to be on finishing up the tasks which contribute to the goal of swapping out GQL for NQL.

@kirrg001
Copy link
Contributor

kirrg001 commented Dec 4, 2018

So these are our chains:

nql-lang -> mingo
nql-lang -> mongo-knex

Each chain sends a result from one third party dependency to another.

This is how i see it.

IMO this test rule for NQL is important:

  • test all chains with a set of fundamental cases
  • a fundamental test suite should ensure the chains work together nicely
  • it's up to us what "fundamental" is
  • e.g. one chain test per "type" (grouping, simple comarison etc)

Reasons:

  • we want to catch a critcial change in any of the dependencies, we don't want to catch edge cases e.g. one case out of 100 failed (the chance of catching this is anyway very low)
  • we want to ensure all the dependencies can communicate with each other - "they speak the same language and commit to it"
  • all of our dependencies we connect together have a pretty good test suite (mingo as well)
  • no need to test all cases or edge cases

IMO the goal should be to not fear updating mingo or our dependencies 🙂

I'd suggest to bring back some more of the integration tests, which were written already 👍


No need to do that now as @ErisDS said, could be tracked in an issue :)

Right now, the focus needs to be on finishing up the tasks which contribute to the goal of swapping out GQL for NQL.

daniellockyer pushed a commit to TryGhost/NQL that referenced this pull request Mar 1, 2022
refs #1

- mongo-knex supports some relation cases already
- forward options to mongo-knex
- remove tests which have a wrong assertions
  - these tests are removed in TryGhost/NQL-old#5 anyway
- this adds the ability to start using relations
- NOTE: relations are not fully supported, only partially
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move tests to mongo-knex/ngl-lang accordingly
3 participants