Many years ago, my team worked on a code coverage ...
# adobe
i
Many years ago, my team worked on a code coverage tool our CF application. We essentially shoved the stack dump for every request into Mongo, then ran some queries that told us a list of all CFM and CFC files and functions had been called across the whole dang thing. Has anyone worked on something of this sort that could be shared? Or does anyone know of a tool that provides this information for a CFML application?
s
testbox does this.
w
fwiw, i've customized cf's classic debugging templates enough to be able to say that there's a wealth of information available that could/should be logged for the scenario you're talking about. were you to create your own custom debug template you could leverage the metrics and reported method executions and add calls to mongo to record the details. it will even let you know what called which function in some circumstances. and then of course you get execution times et al. just a thought
i
@sknowlton Does it compile the data when running tests or when just using the application? Because this is a legacy system and I'd like to generate a report of what I need to keep, then start deleting large chunks of code so I can see what breaks or doesn't. 😛
@websolete We took that data and had a custom bit of code
onRequestEnd
that sent it to the db.
l
testbox also needs FusionReactor to produce code coverage numbers, but you don't need a license for FR to use that functionality. It compiles data while running tests.
i
@Leon Miller-Out You're assuming there are tests.
🙂
l
Yeah, I know that's a dangerous assumption.
You might also be able to use FusionReactor directly and collect execution data from it. testbox is mostly responsible for turning FR's instrumentation on and off and then presenting the data that FR collects.
w
i would still have put the calls to mongo in the debug template itself. first off, the cf debugging template code is ugly as sin (unless changed recently), but if you get it nailed down well enough, then rerunning coverage metrics is nothing more than turning debugging on and using the custom template.
there's all sorts of queries of queries and whatnot in the debug template itself, not sure what's available in onrequestend
l
It's also worth mentioning that FR's coverage metrics seem to fluctuate and unfortunately don't produce 100% reliable results.
We're not sure why that is, but it might have something to do with the complex application/server state picture in most CFML apps.
i
Thanks, I'll see what I can make from those options.
g
I started working on something like this using https://github.com/cfparser/cfparser , but its tricky to make something generic , I believe this project (https://github.com/softwareCobbler/cfc) is giving it a go, and one would hope that the language server they're building for cfbuilder for vscode would provide something like this ?
b
You could take what textbox does with FR's api and run it alongside your app. It's actually fairly easy to get the data, the line-by-line tracking just isn't that perfect.