mirror of
https://github.com/samba-team/samba.git
synced 2024-12-21 09:34:19 +03:00
9754980b03
The index code (lib/ldb_key_value/ldb_kv_index.c) recapitulates LDB expression logic, and it seemed less than completely obvious that it would never make a mistake and return a different result than an unindexed search. Here we run the same search on an unindexed database and on some that have been indexed with a variety of options. We assert that the results are identical over a number of searches. By default, when run from the command line, that number is 495161, which takes a couple of minutes. But if the SKIP_SLOW_TESTS environment variable is set, the number is 33569, which takes 20 seconds or so. In selftest we set the variable and run the smaller number. The tests will print the cumulative search time for each database for each testsuite, like this: $ python3 lib/ldb/tests/python/index_transparency.py ..........................................................[...] <class '__main__.SearchTest'> 25.78186821937561 <ldb connection tdb:///tmp/tmpf1x72x7l/tdb-indexed-dn.ldb> 17.73349642753601 <ldb connection tdb:///tmp/tmpf1x72x7l/tdb-half-indexed.ldb> 15.14864206314087 <ldb connection tdb:///tmp/tmpf1x72x7l/tdb-indexed-guid.ldb> 13.107165575027466 <ldb connection mdb:///tmp/tmpf1x72x7l/mdb-indexed.ldb> Like all benchmarks it is interesting but misleading. One caveat here is that you have (probably) compiled tdb in developer mode without optimisation, while lmdb is probably a system package compiled with -O2, though perhaps not tuned to your exact architecture. Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andreas Schneider <asn@samba.org> |
||
---|---|---|
.. | ||
expectedfail.d | ||
flapping.d | ||
gnupg | ||
knownfail_heimdal_kdc.d | ||
knownfail_mit_kdc.d | ||
knownfail.d | ||
manage-ca | ||
ns | ||
sanitizer | ||
target | ||
checkpassword_arg1.sh | ||
create_smb1_fail_skipfile.txt | ||
devel_env.sh | ||
expectedfail_heimdal | ||
filter-subunit | ||
flapping | ||
format-subunit | ||
format-subunit-json | ||
gdb_backtrace | ||
gdb_backtrace_test.c | ||
gdb_run | ||
in_screen | ||
knownfail | ||
knownfail_heimdal_kdc | ||
knownfail_mit_kdc | ||
knownfail-32bit | ||
no-python-tests.txt | ||
perf_tests.py | ||
quick | ||
README | ||
save.env.sh | ||
selftest.pl | ||
selftest.pl.1 | ||
selftesthelpers.py | ||
skip | ||
skip_mit_kdc | ||
skip-32bit | ||
skip.no-GSS_KRB5_CRED_NO_CI_FLAGS_X | ||
skip.opath-required | ||
slow | ||
slow-none | ||
SocketWrapper.pm | ||
Subunit.pm | ||
subunithelper.py | ||
tap2subunit | ||
tests.py | ||
TODO | ||
todo_smb2_tests_to_port.list | ||
ubsan.supp | ||
valgrind_run | ||
wscript |
# vim: ft=rst This directory contains test scripts that are useful for running a bunch of tests all at once. There are two parts to this: * The test runner (selftest/selftest.pl) * The test formatter selftest.pl simply outputs subunit, which can then be formatted or analyzed by tools that understand the subunit protocol. One of these tools is format-subunit, which is used by default as part of "make test". Available testsuites ==================== The available testsuites are obtained from a script, usually source{3,4}/selftest/tests.py. This script should for each testsuite output the name of the test, the command to run and the environment that should be provided. Use the included "plantest" function to generate the required output. Testsuite behaviour =================== Exit code ------------ The testsuites should exit with a non-zero exit code if at least one test failed. Skipped tests should not influence the exit code. Output format ------------- Testsuites can simply use the exit code to indicate whether all of their tests have succeeded or one or more have failed. It is also possible to provide more granular information using the Subunit protocol. This protocol works by writing simple messages to standard output. Any messages that can not be interpreted by this protocol are considered comments for the last announced test. For a full description of the subunit protocol, see the README file in the subunit repository at http://github.com/testing-cabal/subunit. The following commands are Samba extensions to Subunit: start-testsuite ~~~~~~~~~~~~~~~ start-testsuite: name The testsuite name is used as prefix for all containing tests. skip-testsuite ~~~~~~~~~~~~~~ skip-testsuite: name Mark the testsuite with the specified name as skipped. testsuite-success ~~~~~~~~~~~~~~~~~ testsuite-success: name Indicate that the testsuite has succeeded successfully. testsuite-fail ~~~~~~~~~~~~~~ testsuite-fail: name Indicate that a testsuite has failed. Environments ============ Tests often need to run against a server with particular things set up, a "environment". This environment is provided by the test "target": Samba 3, Samba 4 or Windows. The environments are currently available include - none: No server set up, no variables set. - dc,s3dc: Domain controller set up. The following environment variables will be set: * USERNAME: Administrator user name * PASSWORD: Administrator password * DOMAIN: Domain name * REALM: Realm name * SERVER: DC host name * SERVER_IP: DC IPv4 address * SERVER_IPV6: DC IPv6 address * NETBIOSNAME: DC NetBIOS name * NETIOSALIAS: DC NetBIOS alias - member,s4member,s3member: Domain controller and member server that is joined to it set up. The following environment variables will be set: * USERNAME: Domain administrator user name * PASSWORD: Domain administrator password * DOMAIN: Domain name * REALM: Realm name * SERVER: Name of the member server See Samba.pm, Samba3.pm and Samba4.pm for the full list. Running tests ============= To run all the tests use:: make test To run a quicker subset run:: make quicktest To run a specific test, use this syntax:: make test TESTS=testname for example:: make test TESTS=samba4.BASE-DELETE