[SERVER-21313] should be able to share setup code across multiple tests Created: 05/Nov/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Backlog - Server Tooling and Methods (STM) (Inactive) |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | stm, tig-resmoke | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Tooling & Methods
|
| Participants: |
| Description |
|
Currently we have a huge test (jstests/aggregation/testshard1.js) that tests many different things, and we would like to split it into multiple files. However, tests in this file all rely on some setup code that inserts a bunch of data into a sharded collection. This takes a while, and we would significantly slow down the tests if we split them up by functionality. We should add some logic, probably to resmoke.py, to set up a fixture with some data already loaded. For example, we could specify in the suite's YAML what collections to create, how to shard them, and what data to insert. This way, we could have a bunch of different test files that share a common setup, and can avoid large tests that obscure what they are testing. |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Charlie Swanson [ 05/Nov/15 ] |
|
Ah okay. Yes, as you can see in the description, it's the latter. This is asking for resmoke's fixture to load data, shard collections, etc. before it runs any tests. Feel free to update the title if you can think of a better one. |
| Comment by Scott Hernandez (Inactive) [ 05/Nov/15 ] |
|
I guess I'm asking if it would be sufficient if we simply said that blah*.js all needed data-set4, and they weren't responsible for populating – making it a dependency and requirement before they could be run. When I read the title it sounds like our tests, in javascript, need to be able to share code (which they can, btw, but using a load/include), not that their initial env+data should be provided by resmoke. So it sounds like the task here is to have a resmoke test fixture which includes data loading/cleaning before running a set of tests. |
| Comment by Charlie Swanson [ 05/Nov/15 ] |
|
It's about both sharing data and sharing code. We could get equivalent functionality by making a passthrough in javascript, but that sacrifices the nice evergreen output (logs/failures split per test) and our ability to parallelize the tests. I'm not quite sure what you mean by "getting shared test data/initial-start-conditions together for multiple tests", but I think that is what we're looking for. |
| Comment by Scott Hernandez (Inactive) [ 05/Nov/15 ] |
|
Is this about sharing test data or sharing code? It sounds more like getting shared test data/initial-start-conditions together for multiple tests. |