Test for clock_nanosleep with CLOCK_MONOTONIC (# 3890)

[Sebastian Huber]

On 09/04/2020 15:04, Joel Sherrill wrote:
> On Thu, Apr 9, 2020, 7:43 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 09/04/2020 14:40, Joel Sherrill wrote:
>
>>     On Thu, Apr 9, 2020, 7:28 AM Utkarsh Rai <utkarsh.rai60 at gmail.com
>>     <mailto:utkarsh.rai60 at gmail.com>> wrote:
>>
>>         Hi,
>>         I am willing to add tests for clock_nanosleep with
>>         CLOCK_MONOTONIC. What is the standard way of adding test for
>>         an already present  API but with different configuration? For
>>         eg. should I add  'psxtmclocknanosleep04/ 05/ 06' in the
>>         testsuite?
>>
>>
>>     Yes. That is the pattern.
>     We should try to reduce the count of test programs since on boards
>     with a long reboot time, more tests programs means much more test
>     time (compared to the new test cases alone).
>
>
> And there is the competing factor that you end up with test 
> executables that are overly complex, do not have clean environments 
> for many of the test cases, and are too large to fit on many target 
> boards.
The RTEMS Test framework has checks to ensure that the environment is 
sane before a new test case is executed. It decouples the test cases 
from the runner. This could be used to group test cases to test suites 
depending on the target memory size.
>
> I know you have seen how long the list is of tests that you can't run 
> on many boards.  That's a bad quality attribute

I don't think that tests for clock_nanosleep() will result in big 
executables. The executable size is mostly defined by the feature to be 
tested.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200409/14bc5f6d/attachment-0001.html>