ATF-log archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: #29: Implement race condition tests

#29: Implement race condition tests
  Reporter:  jmmv         |       Owner:  jmmv
      Type:  enhancement  |      Status:  new 
  Priority:  minor        |   Milestone:  0.11
 Component:  MISC         |     Version:      
Resolution:               |    Keywords:      

Comment (by jmmv):

 1. The thing is: how do you express any of this in a portable/abstract
 interface? How do you express that a test case "receives data"? What does
 that exactly mean? I don't think the framework should care about this:
 each test should be free to decide where its data is and how to deal with
  1. Ditto.
  1. Not sure I understand your request, but testing for "unexpected exit
 codes" is already supported. See wiki:DesignXFail for the feature design
  1. What's the problem with this case? The test case exits right away
 after terminating the execution of its body; any open file descriptors,
 leaked memory, etc. die with it.
  1. forking and not waiting for a subprocess was a problem addressed in
 ticket #53.

 I kinda have an idea of what Antti means with "race condition tests", but
 every time I have tried to describe my understanding of matters I seem to
 be wrong. Would be nice to have a clear description of what this involves;
 in particular, what are the expectations from the framework and how should
 the feature be exposed.

 As of now, what I understand by "race condition test" is: a test case that
 exercises a race condition. The test case may finish without triggering
 the race, in which case it just exists with a successful status.
 Otherwise, if the race triggers, the test case gets stuck and times out.
 The result should be reported as an "expected failure" different from

Ticket URL: <>
Automated Testing Framework <>
Automated Testing Framework

Home | Main Index | Thread Index | Old Index