zephyrproject-rtos/zephyr

tests: posix: common: separate into smaller testsuites

Open

#79,454 opened on 2024年10月5日

GitHub で見る
 (9 comments) (0 reactions) (1 assignee)C (15,249 stars) (9,144 forks)batch import
EnhancementGood first issuearea: POSIXarea: Tests

説明

Is your enhancement proposal related to a problem? Please describe. The posix.common testsuite contains a lot of mostly unrelated testsuites. As a result, the code size is large, but mostly the data size is extremely large.

It would require less variation from default settings, and would reduce ram requirements to split that testsuite into smaller groups of more closely related testsuites.

Describe the solution you'd like

The obvious way to group related testsuites is by Option Group.

E.g.

  • POSIX_BARRIERS - #81487
  • POSIX_C_LIB_EXT - #81488
  • POSIX_RW_LOCKS - #80943
  • POSIX_SEMAPHORES - #80964
  • POSIX_SIGNALS - #80930
  • POSIX_SINGLE_PROCESS - #80981
  • POSIX_SPIN_LOCKS - #80965
  • POSIX_SYSTEM_DATABASE - #81489
  • POSIX_THREADS_BASE - #81491
  • POSIX_THREADS_EXT - #81490
  • POSIX_TIMERS - #80807
  • XSI_REALTIME - #83634
  • XSI_REALTIME_THREADS - #86042
  • XSI_SYSTEM_LOGGING - #80986
  • XSI_THREADS_EXT - #81741

and potentially others.

testcase.yaml permutations can be designed to enable or disable features that affect different Option Groups, like TSS, TSA, TSH (see Codes).

Additionally, such a grouping would theoretically improve bug attribution capabilities; if an error was traced (either via stacktrace or bug description) to a certain posix function, there would be a 1:1 correspondance to an Option Group, so typically, only that testsuite would need to be executed.

Describe alternatives you've considered The way the testsuite has been designed historically.

Additional context This came up in the context of #79443 but it was already thought of as a nice-to-have.

コントリビューターガイド