[PATCH 3/3] smpschedsem01: New test Test to verify task priority is inherited from a semaphore.

[Sebastian Huber]

On 2014-06-13 17:29, Joel Sherrill wrote:
>
> On 6/12/2014 8:06 AM, Sebastian Huber wrote:
>> On 2014-06-11 21:18, jennifer wrote:
>>> +++ b/testsuites/smptests/smpschedsem01/smpschedsem01.doc
>>> @@ -0,0 +1,11 @@
>>> +This file describes the directives and concepts tested by this test set.
>>> +
>>> +test set name: smpschedaffinity01
>>> +
>>> +directives:
>>> +
>>> +  - XXX
>>> +
>>> +concepts:
>>> +
>>> +  - Ensure that affinity is honored at task start.
>> This file doesn't match with the subject.  What is the purpose of this test?
>>
>> If you want to test the change priority operation, then you may have a look at:
>>
>> http://git.rtems.org/rtems/tree/testsuites/smptests/smpscheduler03/init.c
>>
> Why are you testing at the Score API level?
>
> Tests should not be written which violate the public APIs unless there
> is a VERY VERY good reason.

It is very difficult to test these state changes with a test using only the 
public API.  For the ready to scheduled state changes you need interrupts. 
Only one state change is impossible in a real system, that is ready to 
scheduled with prepend.

>
> Again, this is another one of those unwritten rules but when you do
> that, there is no proof that the method, argument combination,
> or mode is needed by any API. For example, if you have code in the
> Score which can only be accessed from POSIX and you test directly,
> there is no way from the coverage data to tell that the method
> is not needed when POSIX is disabled. Or that the method isn't
> needed at all.
>
> The only normal paths to _Thread_Change_priority with
> prepend_it set to FALSE is through the core mutex. Which means
> you need to either initialize a mutex the correct way or
> surrender one restoring your priority.
>
> Code is either needed in support of an API or serves no purpose.
> Unit testing at the Score level makes unnecessary code harder to
> find and violates the API boundary.
>

For the code coverage metric this test is worthless, but for a correctness test 
of the implementation it is valuable.  I think we need at least two sets of 
tests, one that targets code coverage and one that simply test the correctness 
of the basic implementation.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.