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
Observe in the browser console output that Running is traced twice.
Expected behavior
The application is only instantiated once, and Running would only print once.
One solution is to avoid linking in these libraries for a non-test build, but it's easy to end up transitively depending on them from other libraries. (In my case we linked to hmm to parse some library info, which ended up depending on utest, and then the HTML5 target suddenly broke.)
The conditional #if utest lines in ApplicationMain seem to assume that this is an actual test suite using a different HTML5 template that doesn't embed the application itself, such as https://github.com/joshtynjala/openfl-utest-sample. One solution might be for test runners to use a define such as -D test to determine if this is an actual test suite as opposed to checking #if (utest || munit). I didn't investigate further to see how feasible this might be.
OpenFL Targets
HTML5
The text was updated successfully, but these errors were encountered:
When I find some time, I intend to clean up this conditional so that tests work with the default html5 template.
I've wondered about that conditional for a number of years, and I just can't come up with a plausible reason why it is there. My best guess is that it's something related to older versions of munit/utest, or older versions of OpenFL/Lime, that has since changed.
…zation when utest is used (closes#2687)
With this conditional compilation, utest cannot be used with the default index.html template, so a custom one was **always** needed. It should just work with the default template.
I'm leaving the munit conditional compilation as-is. I suspect that munit requires this conditional compilation because it doesn't natively support OpenFL (it works with hxml files and doesn't seem to have an option to use project.xml files instead, and it has its own launcher). utest may have been incorrectly included in the conditional compilation at the same time as munit with a wrong assumption that it should work similarly because they're both testing frameworks/libraries.
A user should still be able to create a custom ApplicationMain.hx and index.html to go back to the old behavior. However, I strongly suspect that there's no one who is using utest that needs the old behavior, and that it was just broken.
Describe the bug
If an OpenFL project happens to link to
utest
ormunit
, the application ends up being instantiated twice:embed
call in the HTML5 template:openfl/assets/templates/html5/template/index.html
Line 51 in c114edd
embed
call in theApplicationMain
template, which seems to be specifically for handling test runners:openfl/assets/templates/haxe/ApplicationMain.hx
Lines 21 to 25 in c114edd
This causes havoc as the preloader ends up running twice, loading all assets twice but failing, etc.
To Reproduce
Steps to reproduce the behavior:
haxelib install utest
openfl test html5
Running
is traced twice.Expected behavior
The application is only instantiated once, and
Running
would only print once.One solution is to avoid linking in these libraries for a non-test build, but it's easy to end up transitively depending on them from other libraries. (In my case we linked to
hmm
to parse some library info, which ended up depending onutest
, and then the HTML5 target suddenly broke.)The conditional
#if utest
lines inApplicationMain
seem to assume that this is an actual test suite using a different HTML5 template that doesn't embed the application itself, such ashttps://github.com/joshtynjala/openfl-utest-sample
. One solution might be for test runners to use a define such as-D test
to determine if this is an actual test suite as opposed to checking#if (utest || munit)
. I didn't investigate further to see how feasible this might be.OpenFL Targets
HTML5
The text was updated successfully, but these errors were encountered: