Attempting to run tests against an empty database produces the following:
[SAFETY] β
Database has 0 entries (threshold: 100)
======================================================================
π‘οΈ PRODUCTION SAFETY CHECK ACTIVATED
======================================================================
This database appears to contain real data.
Running the test suite WILL DELETE all data in this database.
This safety check exists to prevent accidental destruction of
production data. If this is truly a test database, you can override.
1. Database Name:
Database "nightscout" doesn't contain "test" in its name
π‘ Use a database name like "nightscout_test" or set TEST_SAFETY_REQUIRE_TEST_DB=false
Override options:
β’ Set TEST_SAFETY_MAX_ENTRIES to a higher value (e.g., 1000)
β’ Set TEST_SAFETY_REQUIRE_TEST_DB=false to allow any DB name
β’ Set TEST_SAFETY_SKIP=true to bypass ALL checks (dangerous!)
======================================================================
This is misleading. A database with 0 entries cannot appear to contain real data. The provided override option of Set TEST_SAFETY_MAX_ENTRIES to a higher value (e.g., 1000) is not relevant.
The suggested fix is a good start, but it doesn't make it clear where the database name is actually set. A user (like me) might try to set CUSTOMCONNSTR_mongo_collection in their my.test.env (from example-template.env) to something like nightscout_test, but this environment variable seems to map to the name of the entries collection which doesn't satisfy the check. Setting nightscout_test in CUSTOMCONNSTR_mongo (ex: mongodb://127.0.0.1/nightscout_test) seems to work as expected.
I am happy to implement some additional conditionals and improved verbiage in producion-safety.js, but I wanted to make sure I wasn't missing anything.
Attempting to run tests against an empty database produces the following:
This is misleading. A database with 0 entries cannot appear to contain real data. The provided override option of
Set TEST_SAFETY_MAX_ENTRIES to a higher value (e.g., 1000)is not relevant.The suggested fix is a good start, but it doesn't make it clear where the database name is actually set. A user (like me) might try to set
CUSTOMCONNSTR_mongo_collectionin theirmy.test.env(from example-template.env) to something likenightscout_test, but this environment variable seems to map to the name of the entries collection which doesn't satisfy the check. Settingnightscout_testinCUSTOMCONNSTR_mongo(ex:mongodb://127.0.0.1/nightscout_test) seems to work as expected.I am happy to implement some additional conditionals and improved verbiage in producion-safety.js, but I wanted to make sure I wasn't missing anything.