From cc650a83b091994cedece08a23a82da1bd61a428 Mon Sep 17 00:00:00 2001 From: John Graley Date: Wed, 14 Feb 2024 18:18:46 +0000 Subject: [PATCH 1/4] Update design_notes.md --- coroutines/design_notes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coroutines/design_notes.md b/coroutines/design_notes.md index ee58e6c44..3e861128c 100644 --- a/coroutines/design_notes.md +++ b/coroutines/design_notes.md @@ -1,6 +1,6 @@ ## Design Notes - - A "corouine" is officially a class or factory object bound to a coro body. + - A "coroutine" is officially a class or factory object bound to a coro body. It creates an RAII object, so an instance must be created and should be in a local scope (i.e. of the test case). Coroutines are implemented as lambdas because a lambda can be a C++20 coroutine, and we can capture the mock objects. From bb43cf558acd5d12c963c63c45182e24b78aac1c Mon Sep 17 00:00:00 2001 From: John Graley Date: Wed, 14 Feb 2024 18:19:26 +0000 Subject: [PATCH 2/4] Update sheared-ordering.md --- coroutines/sheared-ordering.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coroutines/sheared-ordering.md b/coroutines/sheared-ordering.md index d992ce13e..28496eceb 100644 --- a/coroutines/sheared-ordering.md +++ b/coroutines/sheared-ordering.md @@ -1,6 +1,6 @@ ## Notes on hyper-flexible ordering -This analysis is of a version of cotest that allows test corotuines more +This analysis is of a deprecated version of cotest that allows test corotuines more flexibility, so that they can queue up incoming events and then pull them from the queue out of order. From 094b79d2ffea68696caf38903dba5ec15b819a6c Mon Sep 17 00:00:00 2001 From: John Graley Date: Wed, 14 Feb 2024 18:25:18 +0000 Subject: [PATCH 3/4] Update crf_constraints.md --- coroutines/crf_constraints.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/coroutines/crf_constraints.md b/coroutines/crf_constraints.md index c54809c9d..778ad5827 100644 --- a/coroutines/crf_constraints.md +++ b/coroutines/crf_constraints.md @@ -1,32 +1,32 @@ ## CRF Constraints -### 1 -Test setup in coroutine => Test coroutine must run as soon as its constructed, so as to allow it to +### 1. Test setup in coroutine +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 sources. -### 2 -Mock args passed by ref => MUT must not do anything between making a mock call and the coroutine body +### 2. Mock args passed by ref +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 by the mock source. -### 3 -Mock return passed by ref => Test coroutine must not do anything between Return() and the mock source receiving the +### 3. Mock return passed by ref +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 in practice it won't because it's waiting for the return value. -### 4 -Updated cardinality state => coroutine must run so that it can do SATISFY(), RETIRE() or run to exit BEFORE +### 4. Updated cardinality state +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 inside TestCoroutine::DestructionIterations(). -### 5 -Global mock handler finding => After getting an event that is a mock call, test coroutines must call DROP() +### 5. Global mock handler finding +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 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. -### 6 -True event sequence => Most of the time, a LAUNCH() or RETURN() should be followed by NEXT_EVENT() because +### 6. True event sequence +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 case of a second coroutine whose response is to exit. See test case ObserverQueue. From c1c4faf6d2a1cbee9892c16af80ed22ec6d44777 Mon Sep 17 00:00:00 2001 From: John Graley Date: Wed, 14 Feb 2024 18:25:44 +0000 Subject: [PATCH 4/4] Update sheared-ordering.md --- coroutines/sheared-ordering.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coroutines/sheared-ordering.md b/coroutines/sheared-ordering.md index 28496eceb..109cec6ec 100644 --- a/coroutines/sheared-ordering.md +++ b/coroutines/sheared-ordering.md @@ -51,4 +51,4 @@ pull them from the queue out of order. we need to intervene and change the global ordering as seen by GMock search. This should be explicit, since it will have side effects on other coroutines. - - Leads to the PreMockSynchroniser and CRF constraint #5 + - Leads to the PreMockSynchroniser and CRF constraint #6