Getting tests into TestsQueue

[beekayer]

I must be missing something simple that's in my blind spot right now because using the Setting Up page, I cannot seem to get my test function to execute. I've been tracing code in debugger and it boils down to the following:

In my code I call IM_REGISTER_TEST() which calls ImGuiTestEngine_RegisterTest(). This adds the test to vector engine->TestsAll (via push_back) NOT engine->TestsQueue.

Then when I run my app, I see ImGuiTestEngine_ProcessTestQueue() being called which goes through queued tests in engine->TestsQueue. The test I registered is not in that queue; therefore, the for loop that calls ImGuiTestEngine_RunTest() (which appears to be the actual code that will invoke my test function) is never called. So I look to see what adds tests to engine->TestsQueue and the only thing I find is ImGuiTestEngine_QueueTests(). So what calls that? Nothing except for code in imgui_test_suite.cpp (via TestSuite_QueueTests()). I'm not using TestSuiteApp. Is that a requirement to use this test engine?

I'm tempted to call ImGuiTestEngine_QueueTests() myself to get those tests I registered into engine->TestsQueue. If that is the solution, along with the test engine context I have, I think I would pass in group = ImGuiTestGroup_Unknown (to be sure to get all tests I added), filter_str = NULL, and run_flags = ImGuiTestRunFlags_None. It seems like I would probably call this before I call ImGuiTestEngine_Start() because the thread/coroutine will kick off at that point and the test needs to be in the queue first.

I feel like this would have been on the Setting Up page which leads me to think I must be missing something obvious. Any help/advice?

[ocornut]

If you call the test engine UI you can queue them interactively with the UI. Otherwise you can call the queue test function as you said if you want to queue everything. Using “all” will queue all tests.

You can queue test after the coroutine has started.

[ocornut]

Amending my answer now that I am on the computer:

and the only thing I find is ImGuiTestEngine_QueueTests(). So what calls that? Nothing except for code in imgui_test_suite.cpp (via TestSuite_QueueTests()). I'm not using TestSuiteApp. Is that a requirement to use this test engine?

The imgui_test_suite is our own app to test dear imgui and you don't have to use it but it can be a useful reference.

To clarify, this page https://github.com/ocornut/imgui_test_engine/wiki/Setting-Up#other-io

Show the main ImGuiTestEngine_QueueTest() function:
void ImGuiTestEngine_QueueTest(ImGuiTestEngine* engine, ImGuiTest* test, ImGuiTestRunFlags run_flags = 0);

So you can use e.g. `ImGuiTestEngine_QueueTest(engine, "my_test_name");

Which seems rather self explanatory to me, so I am surprised you didn't find this function when looking at the header file.

I will amend that wiki page to give example about using ImGuiTestEngine_QueueTest().

[ocornut]

I have moved the "Registering Tests" section from the Automation API page into the Setting Up pages. Added links to from the former, and reformulated the section into a "Registering and Queuing Tests" section.
I believe this should answer all your questions.

Though TL;DR; in most situations you may have an "interactive" mode of your app which calls ImGuiTestEngine_ShowTestEngineWindows() and a "non-interactive" mode which may call e.g. ImGuiTestEngine_QueueTests(engine, ImGuiTestGroup_Unknown, "all").

Let me know if you have any other questions!

[beekayer]

Which seems rather self explanatory to me, so I am surprised you didn't find this function when looking at the header file.

Agreed. I'm just starting out and was relying too much on the Wiki.

I do need one more piece of advice. My application is a Lua runtime environment. So all of the TestEngine mechanisms are managed by an object I bind to the Lua context. If there's a Lua script error, my application lets you fix the Lua error and reload without exiting the application (thus ImGui context is preserved). Note, the Lua scripts are not in charge of creating and destroying ImGui context, nor creating new frames and rendering them. I am not using 1:1 ImGui -> Lua bindings, basically only widget ImGui API is exposed to Lua. All of this has been working well for years.

I've been able to get TestEngine working well except for one situation. On a reload, I don't destroy the ImGui context and I don't destroy the ImGuiTestEngine either. What I'm trying to do is get the TestEngine to a state where the same tests can be registered again and the TestEngine can be started again. Sequence of actions I'm trying to accomplish:

User has Lua error, fixes Lua error and invokes reload:

1. ImGuiTestEngine_Stop()
2. ImGuiTestEngine_UnregisterTest() <-- go through and unregister all tests because they will be loaded again when the Lua script is run again.
3. .. what I want to do here is ImGuiTestEngine_UnbindImGuiContext() because you can't call ImGuiTestEngine_Start() with the TestEngine still having a reference to the ImGuiContext, but can't because that's a private function.
4. Run Lua script again which does:
5. For each test registered in Lua script: IM_REGISTER_TEST(), ImGuiTestEngine_QueueTest()
6. ImGuiTestEngine_Start() <-- fails assert: IM_ASSERT(engine->UiContextTarget == NULL);

I see that ImGuiTestEngine_DestroyContext() calls ImGuiTestEngine_UnbindImGuiContext() but that's for a complete shutdown. Like I said, I'm keeping the application alive (i.e. I'm not destroying the ImGui context) for a reload. Any advice?