(some_dude912 on Reddit): TypeError: Cannot read property 'line_states' of undefined

[SanderVocke]

(posted by some_dude912 on Reddit @ https://www.reddit.com/r/QML/comments/1aumcfe/comment/kr60ctl/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button):

Awesome idea, coincidentally I was working on something similar at the moment. I have just tried out your tool and I may have used it wrong so I am commenting in hopes of getting some advice on how to proceed: I ran qoverage instrument --in-place (without using --in-place or with any other option I was already getting different errors). Now I cd'd into my tests directory which was one level above the source directory which I instrumented. Now I ran my tests using qmltestrunner ... | tee output.log which is how we currently run our tests. (I also went ahead and tried to run it like qoverage collect -- qmltestrunner ...and got the same results) in the output it shows a lot of errors most of them along the lines of TypeError: Cannot read property 'line_states' of undefined. I assume that it is also due to this that when I then try to create the xml report using the procedure described on github I get only a very minimal xml document only stating 0 branches etc.

[SanderVocke]

Hey there, thanks for posting the first issue! It sounds like something is going wrong in the instrumentation or when running the app. It doesn't sound like you are using it wrong.

After instrumenting with --in-place, the expectation is that it should just run as normal but also generate <QOVERAGERESULT>...</QOVERAGERESULT> lines on stdout when the program exits.

If that is not happening and you are already getting errors during runtime, there is no point moving on to the collection stage. line_states is the name(s) of the variable(s) where the coverage is stored at runtime. Quite strange that the collector object holding the line_states seems to be undefined in your case.

Did you also add -g / --glob to your instrument command to specify which files to include? Can you confirm that your QML files are indeed replaced by instrumented ones?

I am afraid it is a bit hard to continue without seeing what is happening in the code.

• Do you have some context info about your environment? (Qt version, OS)
• Is there any chance you can share your code, or is it private/proprietary?
• Is there a main QML file you could run with just qml, as opposed to qmltestrunner? I ask because in my main project I run qoverage on, I have custom start-up code, but in qoverage's self-tests, qml is used and not qmltestrunner. It should work of course, but maybe I have a bug there.

Just as a sanity check, could you run a very simple "Hello world" QML file? Like this one from the qoverage tests: https://github.com/SanderVocke/qoverage/blob/master/test/examples/basic/main.qml If you just run that with qml main.qml after instrumenting it using qoverage instrument --in-place --glob main.qml, do you see the QOVERAGERESULT line on the stdout?

[SanderVocke]

I can already tell that something needs fixing for using qmltestrunner:

• The TestCase "name" field needs to be added to the property blacklist, annotating it causes errors. It should remain a string literal, no code coverage check.
• At the end of qmltestrunner, the application aboutToQuit signal is not emitted. so the coverage is not dumped.

Unfortunately I used a custom test runner in my own project, and used qml (not qmltestrunner) in qoverage's own tests.

I need to address these issues, but it seems unrelated to your issue about line_states. So my questions above remain.

[SanderVocke]

As for triggering the dump, I have an idea on how to fix this for qmltestrunner (see #55) Edit: This was merged to master, and a test for running with qmltestrunner was added. It works, but a new requirement is that you should add qoverage's import directory (get it with qoverage --importpath) to your QML_IMPORT_PATH when running.

Released as well to PyPi (v0.1.12)

[SanderVocke]

stale.