927c7ecbb0
Adds a fat unit test (integration test?) for BTI index writers and readers. The test generates a small random dataset for the index writer, writes it to a BTI file, and then attempts to run all possible (and legal) sequences (up to a certain length) of index reader operations and check that the results match the expectation (dictated by a "simple" reference index reader). It is currently the only test for this new feature, but I think it's reasonably good. (I validated the coverage by looking at LLVM coverage reports and by manually adding bugs in various places and checking that the test catches it after a reasonably small number of runs). (Note that in a later series, when we hook up BTI indexes to Data.db readers/writers, the feature will also be indirectly tested by the corresponding integration tests). This is a randomized test. As such, its power grows with the number of runs. In particular, a single run has a decently high probability of not exercising parts of the code at all. (E.g. the generated dataset might have no clustering keys). Also this is a slow test. (With the default parameters, ~1s in release mode on my PC, several seconds in debug mode. (And note that this is after a custom parameter downsizing for debug mode, because this test is slowed extremely badly by debug mode, due to the forced preemption after every future)). For those two reasons, I'm not glad to include it in the test suite that runs in CI. Instead of running it once in every CI run, I'd very much rather have it run 10000 times after the tested feature is touched, and before releases. Unfortunately we don't have a precedent for something like that.
Scylla in-source tests.
For details on how to run the tests, see docs/dev/testing.md
Shared C++ utils, libraries are in lib/, for Python - pylib/
alternator - Python tests which connect to a single server and use the DynamoDB API unit, boost, raft - unit tests in C++ cqlpy - Python tests which connect to a single server and use CQL topology* - tests that set up clusters and add/remove nodes cql - approval tests that use CQL and pre-recorded output rest_api - tests for Scylla REST API Port 9000 scylla-gdb - tests for scylla-gdb.py helper script nodetool - tests for C++ implementation of nodetool
If you can use an existing folder, consider adding your test to it. New folders should be used for new large categories/subsystems, or when the test environment is significantly different from some existing suite, e.g. you plan to start scylladb with different configuration, and you intend to add many tests and would like them to reuse an existing Scylla cluster (clusters can be reused for tests within the same folder).
To add a new folder, create a new directory, and then
copy & edit its suite.ini.