WiredTiger tests

60 views
Skip to first unread message

Ron Marcus

unread,
Jan 4, 2024, 3:31:44 AMJan 4
to wiredtiger-users

Hello,

I’m interested in contributing to the open-source WT project. What tests do I need to run to make sure I don’t break existing functionality?

What tests do I need to run? are the following enough?:

  • Running from the build directory:
    • test/unittest/unittests
    • ctest
    • ../test/suite/run.py
    • test/fops/test_fops 
    • test/format/format.sh -t 10 rows=10000 ops=50000


Are there more important tests that I missed?


Thanks,

Ron

Etienne Petrel

unread,
Jan 4, 2024, 3:53:29 AMJan 4
to wiredtig...@googlegroups.com
Hi Ron,

First of all, thank you for your interest in WiredTiger. The team greatly appreciates external contributions!

When submitting a pull request, a set of predefined tests will be triggered to verify most functionalities are working properly and that the code syntax is following our standards. The script that is executed for the code syntax is dist/s_all. You can already execute it and see if it finds errors.

If you want to perform your own tests before proceeding further, the test/format one is a great start:

  • test/format/format.sh -t 10 rows=10000 ops=50000

If you are modifying a specific area of the code, you may find relevant C or python tests to execute. You will find the executables for the C tests in your build directory. For the python tests, you may run one as shown below from your build directory:
  • python3 ../test/suite/run.py <test_name>

For instance, to execute the test test_hs01.py:
  • python3 ../test/suite/run.py hs01

There are many other tests than can be executed, if you are interested in any specific ones, let us know and we would be happy to help! You can also create your own test if you don’t find anything that covers the code you are adding/editing.

Regards

Etienne





{ name     : "Etienne Petrel",
  title    : "Senior Software Engineer, Storage Engines",
  location : "Sydney, AU" }



--
You received this message because you are subscribed to the Google Groups "wiredtiger-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wiredtiger-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wiredtiger-users/c5640f4c-7588-4bf3-ac59-38f40aefa6bdn%40googlegroups.com.

Marc Butler

unread,
Jan 7, 2024, 5:28:31 PMJan 7
to wiredtiger-users
Hi Ron,

Here's another "starter" perspective to add to the one provided by Etienne.

Great to hear you’re interested in the WiredTiger project!

Allow me to provide some context as to how WT is tested, to help in answering your question.


Evergreen is a Continuous Integration tool developed by MongoDB that we use for surprise, surprise: continuous integration! 😀 We define Evergreen build tasks in test/evergreen.yml which the evergreen client then uses to describe the VM to setup, how to build, what specific tests to run, and so on.

The Evergreen build infrastructure is only available to MongoDB employees as the compute time must be paid for by the company.


If you are able to control a fleet of virtual machines, it might be worth trying to set up Evergreen for yourself but we would need to find someone in the team that looks after Evergreen, as the WiredTiger team uses it as a “service”.


We genuinely value that you would like to verify an changes your making, and fFortunately WT itself comes with a multitude of test tools and suites:

  • build/test/format

  • build/test/csuite

  • build/test/cppsuite

  • test/suite (individual python tests)


We would suggest that you start with the test target which can be run in the build directory of your workspace, that is:


$ cmake -B build -G Ninja

$ cd build

$ ninja

# Assuming a successful build.

$ ninja test


Note after you submit a PR it will remain in a suspended state until a WiredTiger team member gives it the okay for the PR to be run on Evergreen. While it is understandable that problems may show up at that point, given the number of systems and configurations we can run against on Evergreen, all the testing you do in preparation is invaluable: it prevents wasted computing time and helps expedite PR (Pull Request) review.


As noted above there is a multitude of tests as you become more comfortable working in the code base you will be able to easily expand and also focus your testing to improve your development cycle time.

All the best,

Marc

Reply all
Reply to author
Forward
0 new messages