Testing

Main Page GitHub Repo Syncfree Project Lightkone Project
Search…
Testing
​Unit Tests​
​System Tests​
​Release Tests​
​Test Logging​
​Utility Functions​
Unit Tests
EUnit is used for unit testing. Unit tests reside in the module they are testing and test the module in isolation. The basic test skeleton should be encapsulated in a TEST block.
1
-ifdef(TEST).
2
main_test_() ->
3
    {foreach,
4
        fun setup/0, fun cleanup/1,
5
        [ fun my_test/1, ... ]
6
    }.
7
​
8
% Setup and Cleanup
9
setup() -> io:format(user,"setup",[]), ...
10
​
11
cleanup(Args_from_setup_return) -> ...
12
​
13
...
14
-endif.
Copied!
All tests can then be executed via make test.
A single module can be tested via rebar3 eunit --module=MODULE_NAME
Log output is consumed; use io:format/3 for debugging purposes
System Tests
System test suite tests a certain aspect of the system and can be either a single data center or a multi-datacenter suite.
A suite should be name ..._SUITE.erl by convention.
To execute system tests, execute one of the following commands
1
make singledc
2
make singledc SUITE=...
3
make multidc
4
make multidc SUITE=...
5
make systests
Copied!
Bucket Namespace
Every system test should have its own bucket namespace defined at the top of the suite. Unique bucket namespaces ensure that test suites do not interfere with each other. The convention is filename with SUITE replaced by bucket. E.g., the bucket for antidote_SUITE.erl should be defined as
1
-define(BUCKET, antidote_bucket).
Copied!
and the macro should be used once at the start of a test case, defining the bucket to be used for that test case. If a unique bucket per test case is needed (e.g. for parallel tests), then
1
-define(BUCKET, test_utils:bucket(antidote_bucket)).
Copied!
can be used instead.
Multiple Data Center System Test Setup
System tests which use multiple data centers are located in the test/multidc folder. The fixed test setup is as follows:
3 interconnected Data center
Data center one has two physical nodes
Release Tests
make reltest tests the antidote release executable.
Test Logging
To log messages in a test suite, use the function ct:log. If a message should be visibile in the printed log (e.g. in travis), then ct:pal or ct:print can be used.
All other logging messages (io, logger) end up in the ct HTML summary, see the generated logs/index.html file and navigate to the test cases you want to see the logs of.
Utility Functions
There are multiple help functions already implemented for common functionality in the test/utils folder. They are separated by functionality into the following files:
antidote_utils
Functions to manipulate antidote data types
riak_utils
Riak cluster management. Useful for multi-dc tests.
time_utils
Time-based helper functions
test_utils
Test initialization and other helper functions which do not fit into the other categories
Development - Previous
Building a Release
Next - Development
Contributing
Last modified 1yr ago
Copy link
Contents
Unit Tests
System Tests
Bucket Namespace
Multiple Data Center System Test Setup
Release Tests
Test Logging
Utility Functions