Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Adapt testcontainers to be testing framework agnostic #82
Adapt testcontainers to be testing framework agnostic #82
Changes from 4 commits
8cd73b2
40bdc7e
4a1c910
3770849
8bad275
59a5484
7924b0d
2c643bd
661370f
7ae9a4a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 looks like a partial hot/cold targeted custom setup which should be irrelevant for generic test clusters and especially in a single-node setup.
@amotl Any reason for this configuration? (as it was in the codebase already).
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.
Yeah, well spotted. It is indeed a configuration detail which is specific to the test cases for
cratedb_toolkit.retention
, where this code was initially conceived for.In this spirit, it should not be part of the generic startup parameters, but at the same time, it shows we need the capacity to configure those details when needed.
@pilosus: Do you think we can improve this spot, so that corresponding configuration settings can be defined on behalf of the snippet in
conftest.py
? This time, it will probably not be so easy, because the test adapter will already need this information at startup time. Maybe you have an idea how to handle this elegantly?While being at it: Of course, it would not just be about the specific
node.attr.storage
parameter, but about any other parameters as well.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, I see you already added
cmd_opts
to the constructor. 🙇https://github.com/crate-workbench/cratedb-toolkit/blob/661370ffb0619e2a4c698c52627c99a1fb726bad/cratedb_toolkit/testing/testcontainers/cratedb.py#L94-L95
So,
{"node.attr.storage": "hot", "path.repo": "/tmp/snapshots"}
would just need to be moved over to the caller.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.
Exactly. And given that we use dict merge, you can even override the default settings
I'll remove the
node.attr.storage
from the default thoughThere 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.
Thanks. What do you think about
path.repo
, @seut? It could be convenient for testing to have it configured by default. Because you didn't mention it in your request, do you think it can stay?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.
@seut @amotl hmm, when I delete
node.attr.storage=hot
tests:
tests/retention/test_cli.py::test_run_delete_basic
tests/retention/test_cli.py::test_run_delete_dryrun
tests/retention/test_cli.py::test_run_reallocate
hang.
Here are the logs:
Interestingly enough,
test_run_delete_with_tags_match
works wellThere 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.
Yeah, the test cases defined for
cratedb_toolkit.retention
need this setting to be configured, so it will need to go intotests/conftest.py
somehow. On the other hand, it should not be part of the generic configuration. That's yet another cliff we need to take.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.
Given the whole chain of the nested fixtures with different scopes, it will either require some more time from me next week, or a simpler solution with
cratedb
override fortests/retention/conftest.py
that havenode.attr.storage=hot
in 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.
We can easily handle that on a later iteration, and/or discuss possible solutions beforehand. Thank you.
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.
Just a nit: I usually write this like that. Is it a good idea?
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.
Is there a reason not to use f-strings already?
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.
Fixed.
Alhough I personally am not a big fan of f-strings, because sometimes people abuse their flexibility with larger expressions and, thus, damage readability. But it's a personal choice rather than anything else. In this particular case it's just fine to use f-strings
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.
First things first: I like that you bundled those bits of information into a little container class.
On the other hand, contrary to
CrateDBFixture
, this section is specific to the test suite forcratedb_toolkit
, and is not meant to be shipped withcratedb_toolkit.testing
.Do you see a chance to decouple this and let it be configured in
tests/conftest.py
, maybe on behalf of just a bit more pytest .request / _conf / -fixture magic, but loosely coupled, so that there is no dependency path going fromcratedb_testing
totests/conftest.py
, and the configuration could be somehow elegantly inverted instead?I am not sure if I am asking for too much here, or if you can follow my thoughts easily, or if the implementation would be too complicated. Please let me know.
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 reset tables aren’t need in testing module and only needed in conftest, I can simply move them there. But in this case shall I still try to remove explicit import of testing/testcontainers? It’s needed for CrateDBFixture. I probably don’t see the whole picture, but utils module is still explicitly imported there, so I don’t quite get why it’s different for testing module
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 specific set of tables are only meant to be reset on behalf of the cratedb-toolkit test suite, which is not being shipped as part of the package. On the other hand,
cratedb_toolkit.testing
intends to bundle generic testing helpers/utilities/fixtures.In this spirit, you made the right choice to put
CrateDBFixture
there, but I think the table definition / test suite configuration itself, now excellently bundled into theTestDrive
container class, should stay intests/conftest.py
. However, it can't be there in isolation, because it will need to be picked up by the genericCrateDBFixture
in some way, because this one actually orchestrates the container lifecycle. Can you figure out a way to make that happen elegantly?Are you referring to one of those? I think both are fine in general. It should be free for every module to use generic utilities from
cratedb_toolkit.testing
, but not the other way round, at least import-wise.Are you referring to this import?
I think it is also perfectly fine. You can pull in all desired utitilities into
conftest.py
, but the tricky part will be to define the test suite database connectivity configuration (TestDrive
) there, and let it be picked up / consumed by the genericCrateDBFixture
to be used properly at runtime, because it can't "import" something fromtests/conftest.py
.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.
So, basically, I've made
CrateDBFixture.reset
method to take reset tables in as a parameter without hardcoding them anyhow. That means,CrateDBFixture
can still live in thecratedb_toolkit/testing/testcontainers/cratedb.py
, but the reset tables are defined in thetests/conftest.py
along with the fixtures that useCrateDBFixture
. I hope this solves your concern with the loose coupling.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.
Yeah this was exactly what I was dreaming up regarding separation of concerns, and where I haven't been able to make any progress so far. Thank you very much for resolving that.
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 appreciate very much bringing this into the generic
cratedb_toolkit.testing
module namespace, to make it a re-usable component for other packages.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.
Talking about "naming things": If you have a better idea for the name, in order to better disambiguate from pytest's notion of "fixtures", because it is actually a testframework-agnostic adapter/wrapper around, well, DatabaseAdapter 1 and CrateDBContainer, please let me know 2.
Footnotes
Also eventually to be renamed to
CrateDBClientAdapter
or something different. ↩As with my other suggestions, the change itself can easily be done on a subsequent iteration. I am just taking the chance to talk with someone about 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.
Would
CrateDBTestAdapter
be a more sensible name?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.
Given that we have
DatabaseAdapter
, I like theCrateDBTestAdapter
name!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.
Wonderful. Let us rename it on behalf of a subsequent patch.
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 see you already renamed it properly, thanks.
I proposed to change it later, because I feared this would add too much noise to this patch because the symbol would need to be changed at too many places. But, of course, it turns out that it already has been nicely decoupled from the test cases on behalf of the
cratedb
andcratedb_service
pytest fixtures, so my fears were unfounded.Check warning on line 192 in cratedb_toolkit/testing/testcontainers/cratedb.py
Codecov / codecov/patch
cratedb_toolkit/testing/testcontainers/cratedb.py#L192
Check warning on line 199 in cratedb_toolkit/testing/testcontainers/cratedb.py
Codecov / codecov/patch
cratedb_toolkit/testing/testcontainers/cratedb.py#L199