feat(testing): class based parametrization and fixtures#1135
Open
feat(testing): class based parametrization and fixtures#1135
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Suggestion for writing tests that resolves all pytest issues I've been having and allows us to parallelize with pytest-xdist (3x speedup on my laptop as of now, expect it to get better as the number of tests grows)
--
(I know there is no buyin for a tag service, we might pivot this week, this just shows how service spec conformity testing would work)
Let's say we'd like to be flexible about where we store tags, we want to be able to exchange providers for tag storage and make sure they all conform to the same spec.
TagCrud is a testing class that tests conformity to this spec.
To make it concrete, you mix it into another class, that instantiates a service we'd like to test, like TestPostgres
this way when we have a RoelofGraphDb, we can just test it with the same TagCrud tests.
most importantly, these classes when tested via pytest-xdist can be executed in parallel giving us significant speedup, yet tests within a class are executed in series, which means that they can have side-effects (CRUD is a good example) and are all run in the same process/thread, which means that setUp and tearDown have to run only once (efficiency and also can have sideeffects (reset the db))