Merge #19592

19592: treewide: fix remaining broken paths to test applications r=maribu a=aabadie



Co-authored-by: Alexandre Abadie <[email protected]>

.murdock

@@ -111,8 +111,8 @@ z1
 "}
 
 : ${TEST_KCONFIG_ENFORCE_APP_GROUPS:="
-tests/cb_mux*
-tests/congure_*
+examples/hello-world
+tests/build_system/external_board_dirs
 tests/drivers/b*
 tests/drivers/f*
 tests/drivers/g*
@@ -128,16 +128,16 @@ tests/drivers/s*
 tests/drivers/t*
 tests/drivers/u*
 tests/drivers/v*
-tests/external_board_dirs
+tests/net/ieee802154_hal
 tests/periph/*
 tests/pkg/elk
 tests/pkg/uzlib
-tests/prng_*
-tests/trace
-tests/xtimer_*
-tests/ztimer_*
-examples/hello-world
-tests/ieee802154_hal
+tests/sys/cb_mux*
+tests/sys/congure_*
+tests/sys/prng_*
+tests/sys/trace
+tests/sys/xtimer_*
+tests/sys/ztimer_*
 "}
 
 # This list prevents boards from being tested by the TEST_KCONFIG_TEST_ALLOWLIST
@@ -155,8 +155,8 @@ tests/ieee802154_hal
 # the kconfig implementations.
 : ${TEST_KCONFIG_TEST_ALLOWLIST:="
 examples/hello-world
-tests/saul
-tests/mtd_mapper
+tests/drivers/saul
+tests/drivers/mtd_mapper
 "}
 
 : ${TEST_WITH_CONFIG_SUPPORTED:="examples/suit_update tests/drivers/at86rf2xx_aes"}

CODEOWNERS

@@ -141,16 +141,16 @@
 /sys/ztimer/ @kaspar030 @bergzand
 
 /tests/ @smlng @leandrolanzieri @aabadie @MichelRottleuthner @fjmolinas
-/tests/candev/  @wosym
+/tests/drivers/candev/ @wosym
 /tests/drivers/bq2429x/ @jeandudey
 /tests/drivers/dht/ @wosym
-/tests/gnrc*  @miri64
-/tests/lwip*  @miri64
+/tests/net/gnrc* @miri64
+/tests/pkg/lwip* @miri64
 /tests/pkg/libschc/ @miri64
-/tests/slip/  @miri64
+/tests/net/slip/ @miri64
 /tests/unittests @miri64
 /tests/*/tests/*.py @miri64
-/tests/cpu_efm32_features/ @basilfx
+/tests/cpu/efm32_features/ @basilfx
 
 # KConfig maintainers will be notified about all KConfig changes
 Kconfig @leandrolanzieri @jia200x @MrKevinWeiss

boards/b-u585i-iot02a/doc.txt

@@ -37,7 +37,7 @@ For using the ST B-U585I-IOT02A board we recommend the usage of the
 [GNU Tools for ARM Embedded Processors](https://launchpad.net/gcc-arm-embedded)
 toolchain.
 
-**Important notice:** With GCC 10, the `tests/malloc` application doesn't work.
+**Important notice:** With GCC 10, the `tests/sys/malloc` application doesn't work.
 To use malloc, prefer GCC 9 which seems to work better.
 
  */

bootloaders/riotboot/doc.txt

@@ -121,7 +121,7 @@ microcontroller is rather straightforward. You need to:
 - Provide the variables `ROM_START_ADDR` and `ROM_LEN` as well as
 `RAM_LEN` and `RAM_START_ADDR`.
 - Adapt the linker scripts for your cpu to pass the test
-[tests/cortexm_common_ldscript](../../tests/cortexm_common_ldscript). This test
+[tests/cpu/cortexm_common_ldscript](../../tests/cpu/cortexm_common_ldscript). This test
 ensures that the linker script supports building firmware's with a rom offset
 and specific sized firmware's.
 - Make the startup code `board_init()`, `cpu_init` idempotent, i.e. whether you

cpu/esp32/doc.txt

@@ -576,11 +576,11 @@ command, for example:
 - RIOT Docker build image installation
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
- make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
+ make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 - Local toolchain installation
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- $ make flash BOARD=esp32-wroom-32 -C tests/shell [Compile Options]
+ $ make flash BOARD=esp32-wroom-32 -C tests/sys/shell/ [Compile Options]
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The `BOARD` variable in the example specifies the generic ESP32 board that uses
@@ -2051,12 +2051,12 @@ installed.
 To use QEMU for ESP32, an application has to be built with `esp_qemu` module
 enabled, for example with local toolchain installation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 or with RIOT Docker build image
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ BUILD_IN_DOCKER=1 DOCKER="sudo docker" \
- USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Instead of flashing the image to the target hardware, a binary image named
@@ -2070,7 +2070,7 @@ QEMU for ESP32 can then be started with command:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ qemu-system-xtensa \
  -s -machine esp32 \
- -drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
+ -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
  -serial tcp::5555,server,nowait
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2099,12 +2099,12 @@ start_test starts a test
 
 To debug the application in QEMU for ESP32, another terminal is required:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
+$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
 
 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
 Copyright (C) 2015 Free Software Foundation, Inc.
 ...
-Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
+Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
 (gdb) target remote :1234
 
 Remote debugging using :1234
@@ -2117,10 +2117,10 @@ QEMU for ESP32 can also be used in RIOT Docker build image. For that purpose
 QEMU has to be started in the Docker container.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ sudo docker run --rm -i -t -u $UID -v $(pwd):/data/riotbuild riot/riotbuild
-riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/shell
+riotbuild@container-id:~$ USEMODULE=esp_qemu make flash BOARD=esp32-wroom-32 -C tests/sys/shell/
 riotbuild@container-id:~$ qemu-system-xtensa \
  -s -machine esp32 \
- -drive file=tests/shell/bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
+ -drive file=tests/sys/shell//bin/esp32-wroom-32/qemu_flash_image.bin,if=mtd,format=raw \
  -serial tcp::5555,server,nowait
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -2144,12 +2144,12 @@ test_shell.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 $ sudo docker docker exec -it <container-id> bash
-riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/shell/bin/esp32-wroom-32/tests_shell.elf
+riotbuild@container-id:~$ xtensa-esp32-elf-gdb tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf
 
 GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a5) 7.10
 Copyright (C) 2015 Free Software Foundation, Inc.
 ...
-Reading symbols from tests/shell/bin/esp32-wroom-32/tests_shell.elf...done.
+Reading symbols from tests/sys/shell//bin/esp32-wroom-32/tests_shell.elf...done.
 (gdb) target remote :1234
 
 Remote debugging using :1234

cpu/esp8266/doc.txt

@@ -59,7 +59,7 @@ To build a RIOT application, simply use the `make` command and specify an
 existing ESP8266 board, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make flash BOARD=esp8266-esp-12x -C tests/shell ...
+make flash BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For more information about the `make` command variables and specific compile
@@ -283,7 +283,7 @@ directory, a RIOT application can be compiled inside RIOT Docker using the
 make command as usual, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make BOARD=esp8266-esp-12x -C tests/shell ...
+make BOARD=esp8266-esp-12x -C tests/sys/shell/ ...
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This will generate a RIOT binary in ELF format.
 
@@ -295,7 +295,7 @@ of the compilations is also accessible on the host system. On the host system,
 the `flash-only` target can then be used to flash the binary.
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-make flash-only BOARD=esp8266-esp-12x -C tests/shell
+make flash-only BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 @note Both steps can also be performed with a single command on the host
@@ -1126,7 +1126,7 @@ For debugging purposes, the application should be compiled with debugging
 information. This can either be done by using the `esp_gdb` module, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/shell
+USEMODULE=esp_gdb make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 [Back to table of contents](#esp8266_toc)
@@ -1162,7 +1162,7 @@ term1> $QEMU/bin/qemu-system-xtensa -M esp8266 -nographic -serial stdio -monitor
 
 where `/path/to/build/dir` is the path to the application build directory
 `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
-`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`. After that you can
+`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`. After that you can
 start `GDB` in second terminal window using command:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1203,7 +1203,7 @@ To start debugging, the application has to be compiled using
 module `esp_gdbstub`, for example:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/shell
+USEMODULE=esp_gdbstub make flash BOARD=esp8266-esp-12x -C tests/sys/shell/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Once, the application is flashed to ESP82666, debugging can be started as
@@ -1223,7 +1223,7 @@ term2> xtensa-esp8266-elf-gdb /path/to/the/build/dir/image.elf
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 where `/path/to/build/dir` is the path to the application build directory
 `$(BINDIR)` where `$ELFFILE.bin` is generated by the `make` command, for example
-`$(RIOTBASE)/tests/shell/bin/esp8266-esp-12x`.
+`$(RIOTBASE)/tests/sys/shell//bin/esp8266-esp-12x`.
 
 3. Connect from `GDB` to the ESP8266 module with command:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1250,7 +1250,7 @@ the application stepwise or just continue the execution using the `continue`
 command. Please note the limitations below. Once you have started the execution
 in `GDB`, you can use `Ctrl-C` in `GDB` or the console window to break it anytime.
 
-If your application uses console inputs (stdio), such as the `tests/shell`
+If your application uses console inputs (stdio), such as the `tests/sys/shell/`
 application, you can type characters in the console window that gdbstub will
 forward to the application. However, the echo of these inputs occur in `GDB`.
 

cpu/saml21/include/periph_cpu.h

@@ -140,7 +140,7 @@ static const gpio_t sam0_adc_pins[1][20] = {
 #define RTT_CLOCK_FREQUENCY (32768U) /* in Hz */
 #define RTT_MIN_FREQUENCY (RTT_CLOCK_FREQUENCY / 512U) /* in Hz */
 #define RTT_MAX_FREQUENCY (RTT_CLOCK_FREQUENCY) /* in Hz */
-/* determined by tests/ztimer_underflow */
+/* determined by tests/sys/ztimer_underflow */
 #define RTT_MIN_OFFSET (8U)
 /** @} */
 

dist/pythonlibs/testrunner/spawn.py

@@ -41,7 +41,7 @@
 TESTRUNNER_RESET_AFTER_TERM = int(os.environ.get('TESTRUNNER_RESET_AFTER_TERM')
  or 0)
 
-# When running e.g. tests/shell_ble we don't want to reset the board, because
+# When running e.g. tests/sys/shell/_ble we don't want to reset the board, because
 # then ble-serial would terminate and the created virtual serial port would get
 # lost. By default the board is reset before the test starts.
 TESTRUNNER_RESET_BOARD_ON_STARTUP = \

dist/tools/compile_test/compile_like_murdock.py

@@ -28,7 +28,7 @@
  `./compile_like_murdock.py -c stm32`
 
  I changed a driver the DHT driver
- `./compile_like_murdock.py -a tests/drivers/dht tests/saul`
+ `./compile_like_murdock.py -a tests/drivers/dht tests/drivers/saul`
 
  I changed a nucleo-f103rb board...
  `./compile_like_murdock.py -a all -b nucleo-f103rb`
@@ -50,10 +50,10 @@
 
 DEFAULT_APPS = [
  "examples/hello-world",
+ "tests/drivers/mtd_mapper",
+ "tests/drivers/saul",
  "tests/pkg/tinyusb_cdc_msc",
- "tests/mtd_mapper",
- "tests/shell",
- "tests/saul"
+ "tests/sys/shell/",
 ]
 
 DEFAULT_BOARDS = [

dist/tools/compile_test/tests/test.sh

@@ -38,7 +38,7 @@ function call_with_defaults {
 function call_with_specific_board_app {
  ${COMPILE_TEST_DIR}/compile_like_murdock.py \
  --boards native \
- --apps tests/shell \
+ --apps tests/sys/shell/ \
  --dry-run
 }
 

dist/tools/vagrant/freebsd/README.md

@@ -31,8 +31,8 @@ See the general vagrant [README.md](../README.md) for more commands.
 Once logged in to the VM you can run compile and run tests e.g.
 
 ```sh
-make -C tests/shell all -j
-make -C tests/shell test
+make -C tests/sys/shell/ all -j
+make -C tests/sys/shell/ test
 ```
 
 Even applications requiring network interface access should be able to work:

doc/doxygen/src/creating-modules.md

@@ -82,7 +82,7 @@ External modules can optionally define the following files:
  module `foo` must be located in `<PATH_IN_EXTERNAL_MODULE_DIRS>/foo`.
 
 An example can be found in
-[`tests/external_module_dirs`](https:/RIOT-OS/RIOT/tree/master/tests/external_module_dirs)
+[`tests/build_system/external_module_dirs`](https:/RIOT-OS/RIOT/tree/master/tests/build_system/external_module_dirs)
 
 Pseudomodules {#pseudomodules}
 =============

doc/doxygen/src/kconfig/kconfig.md

@@ -86,7 +86,7 @@ applied. Note that if any dependency issue occurs, warnings will be generated
 ## Application configuration with Kconfig {#app-config-kconfig}
 To expose application-specific configuration options a `Kconfig` file can
 be placed in the application's folder. For an example of this you can check
-the [tests/kconfig](https:/RIOT-OS/RIOT/tree/master/tests/kconfig)
+the [tests/build_system/kconfig](https:/RIOT-OS/RIOT/tree/master/tests/build_system/kconfig)
 application.
 
 ## Configuration via environment variables {#env-config-kconfig}

doc/doxygen/src/porting-boards.md

@@ -180,11 +180,11 @@ PROGRAMMER ?= openocd
 
 When using high level timers, i.e. `ztimer` there is an overhead in calling
 for @ref ztimer_sleep and @ref ztimer_set functions. This offset can be
-compensated for. It can be measured by running `tests/ztimer_overhead`
+compensated for. It can be measured by running `tests/sys/ztimer_overhead`
 on your board, i.e:
 
 ```shell
-$ BOARD=my-new-board make -C tests/ztimer_overhead
+$ BOARD=my-new-board make -C tests/sys/ztimer_overhead
 main(): This is RIOT!
 ZTIMER_USEC auto_adjust params:
  ZTIMER_USEC->adjust_set = xx
@@ -379,7 +379,7 @@ In this case some special considerations must be taken with the makefiles:
  `include $(RIOTBOARD)/foo-parent/Makefile.*include*`
 
 An example can be found in
-[`tests/external_board_native`](https:/RIOT-OS/RIOT/tree/master/tests/external_board_native)
+[`tests/build_system/external_board_native`](https:/RIOT-OS/RIOT/tree/master/tests/build_system/external_board_native)
 
 # Tools {#boards-tools}
 

drivers/include/pcf857x.h

@@ -195,7 +195,7 @@
  * @note Module `saul_gpio` has to be added to the
  * project to enable SAUL capabilities of the PCF857X driver, e.g.:
  *
- * USEMODULE="pcf8575 saul_gpio" make -C tests/saul BOARD=...
+ * USEMODULE="pcf8575 saul_gpio" make -C tests/drivers/saul BOARD=...
  *
  * ## Using Multiple Devices
  *

examples/gnrc_minimal/Makefile

@@ -34,7 +34,7 @@ CFLAGS += -DCONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF=2 \
 # Change this to 0 show compiler invocation lines by default:
 QUIET ?= 1
 
-EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
+EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
 
 include $(RIOTBASE)/Makefile.include
 

examples/gnrc_networking/Makefile

@@ -68,7 +68,7 @@ endif
 # Change this to 0 show compiler invocation lines by default:
 QUIET ?= 1
 
-EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/external_board_dirs/esp-ci-boards
+EXTERNAL_BOARD_DIRS += $(RIOTBASE)/tests/build_system/external_board_dirs/esp-ci-boards
 
 include $(RIOTBASE)/Makefile.include
 

makefiles/pseudomodules.inc.mk

@@ -590,7 +590,7 @@ PSEUDOMODULES += ztimer64_%
 ## a configurable @ref CONFIG_ZTIMER_AUTO_ADJUST_SETTLE value can be set for this.
 ##
 ## Alternatively CONFIG_ZTIMER_USEC_ADJUST_% values can be set in the BOARDs
-## configuration header board.h. These can be found out by running tests/ztimer_overhead
+## configuration header board.h. These can be found out by running tests/sys/ztimer_overhead
 PSEUDOMODULES += ztimer_auto_adjust
 
 # core_lib is not a submodule

pkg/doc.txt

@@ -96,7 +96,7 @@
  * `foo`must be located in `<PATH_IN_EXTERNAL_PKG_DIRS>/foo`.
  *
  * An example can be found in
- * [`tests/external_pkg_dirs`](https:/RIOT-OS/RIOT/tree/master/tests/external_pkg_dirs)
+ * [`tests/build_system/external_pkg_dirs`](https:/RIOT-OS/RIOT/tree/master/tests/build_system/external_pkg_dirs)
  *
  * RIOT welcomes new and useful packages. If you'd like to share your work,
  * consider [contributing](https:/RIOT-OS/RIOT/tree/master/CONTRIBUTING.md).