[SERVER-75846] Default resmoke runs to running with noPassthrough, or require running with a suite Created: 07/Apr/23  Updated: 16/Jan/24

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Ted Tuckman Assignee: [DO NOT ASSIGN] Backlog - DevProd Correctness
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Correctness
Participants:

 Description   

Currently resmoke defaults to doing setting up a standalone node (as the core suite does). It would be good if the default behavior did no setup that was hidden or implicit. Its easy now to rely on behaviors from the default suite in suites where they may not apply when running on evergreen.



 Comments   
Comment by Ted Tuckman [ 10/Apr/23 ]

I've edited the description to be slightly clearer, does that make more sense now?

Comment by Alex Neben [ 07/Apr/23 ]

I'm a little confused as to the ask here. What is the "extra setup for test runs"?

Comment by Charlie Swanson [ 07/Apr/23 ]

One common scenario we see is that our tests start their own cluster or standalone or whatever, and are supposed to use testDB to connect to that cluster. I believe we use testDB as an idiom to avoid clobbering the global db variable. But because of this it is very easy to accidentally write in your test

db.runCommand({demo: 1});

When what you meant is

testDB.runCommand({demo: 1});

It's almost a force of habit after typing db.runCommand() so many times in other tests.

The fact that we default the test suite to "core" and provide a binding to the db object makes these really tricky to debug! The command you issued appears not to be doing anything - and yet it appears in the test logs! What is happening?!?

It would be great to make this mistake much harder to make, by forcing developers to select the suite, and so to opt in to having 'db' defined.

A linting rule around this would also be good - but typically you wouldn't notice the linter failure until your patch build, after running and debugging it locally - probably experiencing all the pain already.

Generated at Thu Feb 08 06:31:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.