Running CTDB tests: Difference between revisions

From SambaWiki
No edit summary
(More details, reorganise a bit, use only level >=2 headings as per wiki documentation)
Line 1: Line 1:
== Introduction ==
= Starting a ctdb test environment =


CTDB has a standalone test suite, split into several collections:
$ cd ctdb

$ ./tests/local_daemons.sh foo setup -P /dev/null
;UNIT
:Tests that do not require CTDB daemons. Useful for testing particular subsets of the CTDB code.
;INTEGRATION
:Tests that require a cluster of CTDB daemons. These can be run as an unprivileged user against local CTDB daemons on a test or development machine. Most will also run against a real (or virtual) cluster of nodes - those that do not will be skipped. Each test case will start the CTDB daemons beforehand and stop them afterwards.
;CLUSTER
:These tests require a real (or virtual) cluster of nodes, plus an additional test node. These tests ''can not'' be run on a single test or development machine (without virtualising the cluster nodes). Each test case will start the CTDB daemons beforehand and stop them afterwards.

Examples below assume they are run from within the '''ctdb/''' subdirectory.

== Running tests ==

To run all the UNIT tests:

$ ./tests/run_tests.sh UNIT/

See '''ctdb/tests/README''' for more detailed information on how to run tests.

== Starting a CTDB local daemons test environment ==

<code>./tests/local_daemons.sh</code> can be used to start a local daemons test environment. This is the same environment that is used in the INTEGRATION and CLUSTER test collections.,

$ ./tests/local_daemons.sh foo setup
$ ./tests/local_daemons.sh foo start all
$ ./tests/local_daemons.sh foo start all
$ ./tests/local_daemons.sh foo onnode 0 ctdb status
[wait a while]
[wait a while]
$ ./tests/local_daemons.sh foo print-log all | less
$ ./tests/local_daemons.sh foo print-log all | less


The first argument (<code>foo</code> in the above example) is a daemon configuration directory.
= Running tests =


See <code>./tests/local_daemons.sh -h</code> for usage information.
$ tests/run_tests.sh UNIT/


Individual commands can also have their usage shown (e.g. <code>./tests/local_daemons.sh foo setup -h</code>). Note that a daemon configuration directory must be given for this to work.
See '''ctdb/tests/README''' for general information on how to run tests locally.

Revision as of 00:26, 5 March 2020

Introduction

CTDB has a standalone test suite, split into several collections:

UNIT
Tests that do not require CTDB daemons. Useful for testing particular subsets of the CTDB code.
INTEGRATION
Tests that require a cluster of CTDB daemons. These can be run as an unprivileged user against local CTDB daemons on a test or development machine. Most will also run against a real (or virtual) cluster of nodes - those that do not will be skipped. Each test case will start the CTDB daemons beforehand and stop them afterwards.
CLUSTER
These tests require a real (or virtual) cluster of nodes, plus an additional test node. These tests can not be run on a single test or development machine (without virtualising the cluster nodes). Each test case will start the CTDB daemons beforehand and stop them afterwards.

Examples below assume they are run from within the ctdb/ subdirectory.

Running tests

To run all the UNIT tests:

$ ./tests/run_tests.sh UNIT/

See ctdb/tests/README for more detailed information on how to run tests.

Starting a CTDB local daemons test environment

./tests/local_daemons.sh can be used to start a local daemons test environment. This is the same environment that is used in the INTEGRATION and CLUSTER test collections.,

$ ./tests/local_daemons.sh foo setup
$ ./tests/local_daemons.sh foo start all
$ ./tests/local_daemons.sh foo onnode 0 ctdb status
[wait a while]
$ ./tests/local_daemons.sh foo print-log all | less

The first argument (foo in the above example) is a daemon configuration directory.

See ./tests/local_daemons.sh -h for usage information.

Individual commands can also have their usage shown (e.g. ./tests/local_daemons.sh foo setup -h). Note that a daemon configuration directory must be given for this to work.