You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coroutines are available since C++20 which was published almost four years ago. One of the coroutine use-cases is to do asynchronous I/O. Number of codebases doing this gets larger and larger. And yet, there is no native support to test such code with GTest.
Consider this example/wish:
TEST(ImageDownloaderTest, example)
{
setUpMocks();
auto url = co_awaitresolveImageUrl("my-image");
ASSERT_EQ(url, "https://....");
auto img = co_awaitdownloadImage(url);
ASSERT_EQ(img.size(), 2048);
}
I say "native support" because in principle such code is already testable, but it requires to repeat the same boiler plate for each test case. It is also not possible to use ASSERT_* macros because they internally use return. This cannot be fixed on client side without defining custom macros which would rely on internal details of GTest.
Describe the proposal.
Define CO_TEST and CO_TEST_F macros to be coroutine versions of resp. TEST and TEST_F. They can be possibly implemented as (some details are omitted):
Boilerplate code is hidden inside TestBody() and the test itself is defined inside CoTestBody(). The coroutine type (here MyCoro) needs to be customizable because of the spawn() method. It is intended to start the machinery needed to execute coroutines (e.g. run an event loop) and this action would be different for different coroutine libraries/frameworks used in a project. I would leave the exact way, how to achieve this, our of scope for now.
Finally, define CO_ASSERT_* macros as coroutine friendly versions of ASSERT_*. They would do co_return instead of return. Or is there a way to distinguish if a macro is invoked inside a coroutine vs. a normal function?
Is the feature specific to an operating system, compiler, or build system version?
C++20 or later.
The text was updated successfully, but these errors were encountered:
Does the feature exist in the most recent commit?
No.
Why do we need this feature?
Coroutines are available since C++20 which was published almost four years ago. One of the coroutine use-cases is to do asynchronous I/O. Number of codebases doing this gets larger and larger. And yet, there is no native support to test such code with GTest.
Consider this example/wish:
I say "native support" because in principle such code is already testable, but it requires to repeat the same boiler plate for each test case. It is also not possible to use
ASSERT_*
macros because they internally usereturn
. This cannot be fixed on client side without defining custom macros which would rely on internal details of GTest.Describe the proposal.
Define
CO_TEST
andCO_TEST_F
macros to be coroutine versions of resp.TEST
andTEST_F
. They can be possibly implemented as (some details are omitted):Boilerplate code is hidden inside
TestBody()
and the test itself is defined insideCoTestBody()
. The coroutine type (hereMyCoro
) needs to be customizable because of thespawn()
method. It is intended to start the machinery needed to execute coroutines (e.g. run an event loop) and this action would be different for different coroutine libraries/frameworks used in a project. I would leave the exact way, how to achieve this, our of scope for now.One possible coroutine type implementation:
Finally, define
CO_ASSERT_*
macros as coroutine friendly versions ofASSERT_*
. They would doco_return
instead ofreturn
. Or is there a way to distinguish if a macro is invoked inside a coroutine vs. a normal function?Is the feature specific to an operating system, compiler, or build system version?
C++20 or later.
The text was updated successfully, but these errors were encountered: