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
What I am trying to do: I am trying to use this to generate a LCOV unit test coverage report.
For me to do this, I can easily get which lines are hit by the debugger because this comes from the implementation of DebugFrame - easy peasy. However, the difficulty for me comes from identifying which other lines inside a file are executable in their own right - so I can easily say these are the lines I have hit with my tests and these are the lines that still need to be hit.
So far in order for me to conclude which lines are executable, I am loading the source JavaScript file and iterating through its lines. When looking at a line I am doing various string comparisons to see if said line is executable in the first place. If it is executable I am going to take note of that, if not I move on. Not an elegant solution at all, but it works.
My questions:
If I would like to find all the lines that are executable in a script, is there a more elegant solution as opposed to the above?
Given a script source / file path, is there a way to generate an AST that I can look at to see which lines are executable and which are not?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
I have a not-so-simple question, so please bare with me while I try and explain what I am trying to do.
I started to implement something similar to this: https://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/bundles/org.eclipse.wst.jsdt.debug.rhino.debugger/src/org/eclipse/wst/jsdt/debug - with some quirks and perks.
What I am trying to do: I am trying to use this to generate a LCOV unit test coverage report.
For me to do this, I can easily get which lines are hit by the debugger because this comes from the implementation of
DebugFrame
- easy peasy. However, the difficulty for me comes from identifying which other lines inside a file are executable in their own right - so I can easily say these are the lines I have hit with my tests and these are the lines that still need to be hit.So far in order for me to conclude which lines are executable, I am loading the source JavaScript file and iterating through its lines. When looking at a line I am doing various string comparisons to see if said line is executable in the first place. If it is executable I am going to take note of that, if not I move on. Not an elegant solution at all, but it works.
My questions:
Beta Was this translation helpful? Give feedback.
All reactions