Table of contents
Test file is admmgmt_test.nim. This module tests several APIs defined in admmgmt module. The admmgmt mainly tests for administration commands such as dropDatabase, dropCollection, listCollections, and many more mentioned in the documentation.
Test file is bson_test.nim. This extensively tests Bson module for several BsonDocument tests together with its use case.
Test file is client_test.nim. This extensively tests client module.
Test file is collections_test.nim. This tests extensively Collections which used widely for any casual lib user. Common operations implemented here such as insert, remove, update and many more.
Test file is crud_test.nim. This tests CRUD operations in low level defined in crud.nim module. Collections offloads many of its CRUD operations to this module.
Test file is gridfs_test.nim. This tests GridFS and GridStream functionalities. GridFS commands uploading/downloading and the bucket creation while GridStream acts as file abstraction above GridFS functions. For full available APIs can be checked here.
Test file is test_replication_sslcon.nim. This test any replication operations maintenance starting from
seting it up, connecting through the mongodb+srv
scheme, emulating fake DNS server for testing the
mongodb+srv
scheme. The APIs are following the Mongodb Page for Replication commands which implemented
in Replication module.
Changestream is Mongodb functionality to watch any happening to specific collection and the kinds of
events we want to watch. Changestream needs the mongo clustered as replication set so it’s reusing
the same configuration with replication set test above.
Changestream itself is implemented in Changestream module
By default, these tests take the variables defined as compile-arguments constants in file utils_test.nim
, if the user wants to run in other machine/platform, specify the options on config.nims
in rootdir project.
For example
git clone https://github.com/mashingan/anonimongo
cd anonimongo
cat <<EOF > config.nims
switch("define", "ssl") # if the user wants to connect to SSL/TSL enabled Mongo server
switch("define", "key=/path/to/my/key-file") # key file for SSL/TLS connection
switch("define", "cert=/path/to/my/cert-file") # cert file for SSL/TLS connection
switch("define", "nomongod") # to disable running new mongod
# process and connect to current
# running mongod process
# defining filename is required when the user wants to run `gridfs_test.nim`
switch("define" "filename=/path/to/big/file/to/upload")
switch("define" "saveas=save_as_other_name_file.mkv_for_example")
# enabling replication set test
switch("define", "testReplication=yes")
EOF
# now running the test
nimble test
For reference, this is my own config.nims
for my local setting:
switch("define", "filename=D:/Downloads/Date A Bullet [Preview] [1080p].mp4")
switch("define", "saveas=date_bullet_preview.mp4")
switch("define", "key=")
switch("define", "cert=")
switch("define", "testReplication=yes")
switch("define", "testChangeStreams=yes")
switch("define", "uri")
switch("define", "existingMongoSetup")
switch("define", "exe=D:/Installer/mongodb6.0.6/bin/mongod.exe")
switch("define", "dbpath=D:/Dev/mongodata-v6")
"ConvFromXToItselfNotNeeded".hint off
Also in Github action.
Any others variable can be checked in that utils_test.nim.
In the platform where these tests run, the Mongo server only boot-up when the any of test running
(except test_bson_test.nim
) and then shutdown the Mongo server before the test ends. This only works
when the Mongo server host in localhost
. Define nomongod
option (like example above) to disable
booting up Mongo server.
We can choose which mongod executable we want to run by defining value for exe
e.g. -d:exe=/some/path/to/mongod
and supplying the dbpath
e.g. -d:dbpath=/where/the/dbpath/reside
. See the example above by setting
file config.nims
.
Each test (with exception test_bson_test.nim
) will create a new Database and its related collections and
immediately drop the database and the collections to avoid polluting the database.
In case user wants to have a different scenario, for example, inserting several bson documents and leave
it intact without removing it or dropping the collections or database, the user can write his/her own
test scenario.