Leandro Lanzieri bab6f4737c net/gcoap: Move config macros to 'CONFIG_' namespace
Macros that changed:
GCOAP_MSG_QUEUE_SIZE -> CONFIG_GCOAP_MSG_QUEUE_SIZE
GCOAP_NO_AUTO_INIT -> CONFIG_GCOAP_NO_AUTO_INIT
GCOAP_NO_RETRANS_BACKOFF -> CONFIG_GCOAP_NO_RETRANS_BACKOFF
GCOAP_NON_TIMEOUT -> CONFIG_GCOAP_NON_TIMEOUT
GCOAP_OBS_CLIENTS_MAX -> CONFIG_GCOAP_OBS_CLIENTS_MAX
GCOAP_OBS_OPTIONS_BUF -> CONFIG_GCOAP_OBS_OPTIONS_BUF
GCOAP_OBS_REGISTRATIONS_MAX -> CONFIG_GCOAP_OBS_REGISTRATIONS_MAX
GCOAP_OBS_VALUE_WIDTH -> CONFIG_GCOAP_OBS_VALUE_WIDTH
GCOAP_PDU_BUF_SIZE -> CONFIG_GCOAP_PDU_BUF_SIZE
GCOAP_PORT -> CONFIG_GCOAP_PORT
GCOAP_RECV_TIMEOUT -> CONFIG_GCOAP_RECV_TIMEOUT
GCOAP_REQ_OPTIONS_BUF -> CONFIG_GCOAP_REQ_OPTIONS_BUF
GCOAP_REQ_WAITING_MAX -> CONFIG_GCOAP_REQ_WAITING_MAX
GCOAP_RESEND_BUFS_MAX -> CONFIG_GCOAP_RESEND_BUFS_MAX
GCOAP_RESP_OPTIONS_BUF -> CONFIG_GCOAP_RESP_OPTIONS_BUF
GCOAP_TOKENLEN -> CONFIG_GCOAP_TOKENLEN
2020-01-28 11:59:52 +01:00
..
2019-11-27 13:35:57 +01:00
2019-10-10 10:47:38 +02:00
2019-11-23 22:39:07 +01:00
2019-10-10 10:47:38 +02:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00
2018-06-11 19:12:02 +02:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:36 +01:00
2019-12-20 06:51:34 +01:00
2019-11-23 15:06:54 +01:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00
2020-01-14 13:23:25 +01:00
2019-11-23 22:39:37 +01:00
2019-11-23 22:39:37 +01:00
2018-12-04 00:01:42 +01:00
2019-11-27 20:53:14 +01:00
2019-11-27 14:12:12 +01:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00
2019-11-23 22:39:07 +01:00

Running and creating tests

There are a number of tests included in RIOT. They are located in the tests folder. These tests allow basic functionality to be verified as well as provide an example of usage.

Implementing automated tests

The goal is to be able to run all tests in a sequential way for as many targets as possible.

As some board can't be reset without a manual trigger tests should be implemented with some kind of synchronization. This can be done in two ways:

  • use test_utils_interactive_sync when uart input/output does not need to be disabled for the test. This is enabled by default.
  • set up the test in a loop so the test script will be able so sync with some kind of start condition in the test.

The module for the first option is test_utils_interactive_sync and is set as a default module in Makefile.tests_common. It can be disabled by setting in the application makefile DISABLE_MODULE += test_utils_interactive_sync. The python test script will adapt to it automatically.

Running automated tests

Some tests can be performed automatically. The test automation scripts are defined in the <test_application>/tests/ folder. They are written in python and interact through the uart with the test application code running on a board to do the validation. It is recommended to flash the board with the test just before running it because some platforms cannot be reset while testing.

From the test application directory run:

BOARD=<board_of_your_choice> make flash test

An automated way of knowing if a test is available is to execute the 'test/available' target from the test application directory. It executes without error if tests run by 'make test' are present.

make test/available

Automated Tests Guidelines

When using pexpect $ is useless for matching the end of a line, instead use \r\n(pexpect end-of-line).

Beware of + and * at the end of patterns. These patterns will always get a minimal match (non-greedy).(pexpect end-of-patterns) This can be an issue when matching groups and using the matched groups to verify some kind of behavior since * could return an empty match and + only a subset.

This is especially prevalent since printf() is buffered so the output might not arrive in a single read to pexpect.

To avoid this make sure to match a non-ambiguous character at the end of the pattern like \r\n, \s, \), etc..

don't:

    child.expect(r'some string: (\d+)')

do:

    child.expect(r'some string: (\d+)\r\n')
    child.expect(r'some string: (\d+)\s')
    child.expect(r'some string: (\d+) ,')

Interaction through the uart

Tests implemented with testrunner use the cleanterm target that provides an interaction without adding extra text output or input handling. It can currently be expected to have unmodified line based interaction with the board.

The expected behavior is verified with the test in tests/test_tools.

Tests cannot rely on having on all boards and terminal programs:

  • unbuffered input
  • allowing sending special characters like ctrl+c/ctrl+d