-
-
Notifications
You must be signed in to change notification settings - Fork 7
Conversation
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. |
Are the removed tests covered in nql-lang? |
I think this needs to stay Because mingo is used in NQL. There is no repository. |
yes, the suite is a lot more extensive there - https://github.com/NexesJS/NQL-Lang/blob/master/test/parser.test.js#L16
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? |
Cool. Did you compare both and check for missing cases which were covered in this repo, but not covered in nql-lang? |
Yeah makes sense. filter -> nql -> nql-lang -> mingo |
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.
yes 💯 the path which takes for filter to be transformed into JSON or SQL statement. |
Yeah. I think we should not remove everything and leave one test per use case in this PR? |
I didn't check assertion by assertion, but each |
@kirrg001 done the changes discussed above ;) |
I'd suggest to ask John tomorrow to enable travis for NQL. Then we can run this PR on travis. |
@kirrg001 linting is failing with a ton of errors, do we wanna skip it for now? |
Did you bump eslint plugin to the latest? |
Nope. Will try it now |
|
…esting of querySQL
c5bac0a
to
31905da
Compare
@kirrg001 rebased upon master, lmk if we can 🚢 this |
@gargol up to you. either we merge it now or tomorrow when travis is enabled 🤘🏽👻 |
Would do travis as a separate PR. Don't want to deal with rebases too much 😸 |
Yeah 100% separate PR. Just wanted to see if the PR passes. But feel free to merge this already :) Doesn't rly matter |
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'); |
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.
If this is purely for testing, surely it should live within the test directory?
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.
Good point 👍 Was following the structure in mongo-knex. Will change it in both places
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. |
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? |
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 |
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. |
So these are our chains: nql-lang -> mingo 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:
Reasons:
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 :)
|
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
closes #4
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