Divide API test fixtures into two
See original GitHub issueAt the moment we have one api_session
context manager that creates the gRPC server, then a channel, and yields this to the test client.
However, we should really have an api
fixture that creates the gRPC server, and a context manager that manages the session (just channel).
This would probably speed up testing by a whole lot.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Is it possible to use a fixture in another fixture and both in a test?
An advantage of composing fixtures like that is that they can be used independently, e.g. the last test actually calls the API, simply...
Read more >Tutorial 4: Using Test Fixtures - ReFrame - Read the Docs
A fixture in ReFrame is a test that manages a resource of another test. Fixtures can be chained to create essentially a graph...
Read more >Organize Tests | Basic Guides | Guides | Docs - TestCafe
This topic describes how to organize test code, declare fixtures, tests, and hooks. ... The test controller provides access to the TestCafe test...
Read more >How to modularize your py.test fixtures - gists · GitHub
This is a good way to parameterize the fixtures by creating another function(sum) under them(sum2Nbrs). Calling the function directly mentioning the fixture ......
Read more >Add clojure.test api for fixtures on individual deftests
Inclusion of wrapping logic occludes actual test focus. It's cumbersome to wrap with multiple fixtures (lots of indentation).
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
To find bugs where we accidentally store state in the servicer instead of the database, I prefer instantiating it on demand and throwing it away. Since it should have no state, it should be super cheap to instantiate.
No, we should short-circuit it without using TCP at all.