coffee/googletest
1
0
Fork 0
mirror of https://github.com/google/googletest.git synced 2025-12-07 01:06:50 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update crf_constraints.md

Browse Source
This commit is contained in:
John Graley 2024-02-14 18:25:18 +00:00 committed by GitHub
parent bb43cf558a
commit 094b79d2ff
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
coroutines/crf_constraints.md
View File

@ -1,32 +1,32 @@
## CRF Constraints ## CRF Constraints
### 1 ### 1. Test setup in coroutine
Test setup in coroutine => Test coroutine must run as soon as its constructed, so as to allow it to Test coroutine must run as soon as its constructed, so as to allow it to
create mock objects, watches etc before the mock source runs. Also in phase 2, coroutine can create mock create mock objects, watches etc before the mock source runs. Also in phase 2, coroutine can create mock
sources. sources.
### 2 ### 2. Mock args passed by ref
Mock args passed by ref => MUT must not do anything between making a mock call and the coroutine body MUT must not do anything between making a mock call and the coroutine body
receiving the args. Note that the coroutine CAN run during this period, since the args are owned receiving the args. Note that the coroutine CAN run during this period, since the args are owned
by the mock source. by the mock source.
### 3 ### 3. Mock return passed by ref
Mock return passed by ref => Test coroutine must not do anything between Return() and the mock source receiving the Test coroutine must not do anything between Return() and the mock source receiving the
return value. Mock source could in principle run during this period, since coro owns the return object, but return value. Mock source could in principle run during this period, since coro owns the return object, but
in practice it won't because it's waiting for the return value. in practice it won't because it's waiting for the return value.
### 4 ### 4. Updated cardinality state
Updated cardinality state => coroutine must run so that it can do SATISFY(), RETIRE() or run to exit BEFORE Coroutine must run so that it can do SATISFY(), RETIRE() or run to exit BEFORE
allowing GMock/CotestWatcher code to query eg IsSatisfied() etc. This is extra_iteration_requested reason allowing GMock/CotestWatcher code to query eg IsSatisfied() etc. This is extra_iteration_requested reason
inside TestCoroutine::DestructionIterations(). inside TestCoroutine::DestructionIterations().
### 5 ### 5. Global mock handler finding
Global mock handler finding => After getting an event that is a mock call, test coroutines must call DROP() After getting an event that is a mock call, test coroutines must call DROP()
ACCEPT() or RETURN() on the event before doing anything elase with the cotest UI. This is because the ACCEPT() or RETURN() on the event before doing anything elase with the cotest UI. This is because the
process of deciding which expectation or coroutine will handle the call is global and must complete before process of deciding which expectation or coroutine will handle the call is global and must complete before
anything happens that could generate more mock calls. anything happens that could generate more mock calls.
### 6 ### 6. True event sequence
True event sequence => Most of the time, a LAUNCH() or RETURN() should be followed by NEXT_EVENT() because Most of the time, a LAUNCH() or RETURN() should be followed by NEXT_EVENT() because
they will usually lead to an event for the test coro to pick up and handle. There is an exception in the they will usually lead to an event for the test coro to pick up and handle. There is an exception in the
case of a second coroutine whose response is to exit. See test case ObserverQueue. case of a second coroutine whose response is to exit. See test case ObserverQueue.