Fix tests by delaying get render engine calls

[iche033]

🦟 Bug fix

Targets #429

Summary

Changes:

• moved rendering::engine calls to after the window had a chance to load the engine in tests. Otherwise the engine will be loaded in the main test thread and subsequent render calls will fail.
• reinstated calls to unload engine

This does not fix the INTEGRATION_camera_tracking test as it could be a different issue. I haven't been able to reproduce that locally yet.

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[codecov]

Codecov Report

Merging #535 (67d02aa) into fix_tests (f81686a) will decrease coverage by 0.07%.
The diff coverage is n/a.

❗ Current head 67d02aa differs from pull request most recent head acfcafc. Consider uploading reports for the commit acfcafc to get more accurate results

@@              Coverage Diff              @@
##           fix_tests     #535      +/-   ##
=============================================
- Coverage      69.19%   69.13%   -0.07%     
=============================================
  Files             44       44              
  Lines           4938     4938              
=============================================
- Hits            3417     3414       -3     
- Misses          1521     1524       +3     

Impacted Files	Coverage Δ
src/plugins/minimal_scene/MinimalScene.hh	100.00% <ø> (ø)

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[iche033]

hmm tests are fixed on focal but still failing on jammy

[azeey]

Looking at https://doc.qt.io/qt-5/qthread.html, it says

It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots and invoked methods will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread.

But our RenderThread class does implement a few slots even though it's a QThread. Should RenderThread be implemented using the worker-object approach?

[iche033]

the implementation is based on an Qt example showing how to integrate opengl apps into QML. In that example, it also uses a QThread with slots. I can't seem to find the example any more so it could be outdated. There is this new example: https://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html. The approach is different. It maybe worth investigating the new approach later, e.g if we decide to upgrade to Qt6.

[azeey]

Okay, I took a closer look and I see that our RenderThread class does not implement run, which means the default implementation will be used, which calls QThread::exec and starts the event loop for that object. I think it's essentially doing what the worker-object approach would be doing.