chinhodado / codecoverage_presenter Goto Github PK

in a query we show a nice list of files, but the test related files are not that useful for most people.

We can hide or show at the bottom (or even strikethrough/color) these type of files:
resource://testing-common
chrome://mochikit
chrome://mochitests
chrome://specialpowers

ideally each file that is displayed in the UI as part of a query would have a tag associated with it- all of the above ones should have a 'test file' tag and we can make the UI match what we want.

ActiveData is agnostic about the client libraries you use. Your code can completely liberate itself from the modevlib library by using $.ajax() (which uses callbacks), like so...

    var search = function(query, callback){
        $.ajax({
            url: "https://activedata.allizom.org/query",
            data: JSON.stringify(query),
            success: callback
        });
    };

here is a case where we only seem to have a unique source file of itself:
http://chinhodado.github.io/codecoverage_presenter/?buildRevision=232db2940e992fe4c998dbb0a498703fbf463e0d&query=2&select2=chrome%3A%2F%2Fmochitests%2Fcontent%2Fbrowser%2Faddon-sdk%2Ftest%2Fbrowser_sdk_loader_js_modules.js

in the test selection field if there is only lines covered from the test case itself (or I would argue any test related file), then we shouldn't show it.

The trick here is that we would need to run the query for all test files- this is the case to argue for adding more meta data into active data (post ingestion task)

Changing the function parameter names will simplify the functions using those parameters:

function executeQuery1(param) {
    var test = param.test;
    var buildRevision = param.buildRevision;
    var query = {
        "limit": 10000,
        "where": {
            "eq":{
                "test.url": test,
                "build.revision": buildRevision
            }
        },
        "groupby": ["source.file"],
        "from": "coverage"
    };

can be changed to

function executeQuery1(eqParam) {
    var query = {
        "limit": 10000,
        "where": {
            "eq":eqParam
        },
        "groupby": ["source.file"],
        "from": "coverage"
    };

if your calls parameters are changed

executeQuery1({
    "test.url": test
    "build.revision": buildRevision
})

this allows you to add additional filters with no change to the called code:

executeQuery1({
    "test.url": test
    "build.revision": buildRevision,
    "build.platform": "linux64"
})

You could bring this a step further, and accept a whole where clause ias a parameter:

function executeQuery1(where) {
    var query = {
        "limit": 10000,
        "where": where,
        "groupby": ["source.file"],
        "from": "coverage"
    };

Your call is more complicated,

executeQuery1({"eq": {
    "test.url": test
    "build.revision": buildRevision,
}});

... but you have more sophisticated filtering options:

executeQuery1({"and":[
    {"gt":{"run.timestamp":{"date":"yesterday"}}},
    {"eq": {
        "test.url": test
        "build.revision": buildRevision,
    }}
]})

right now we have a very long select box to find the test we are looking for, I would prefer to search for one, so typing |whitelist| would show all test filenames which match .whitelist.

load this:
http://chinhodado.github.io/codecoverage_presenter/?buildRevision=232db2940e992fe4c998dbb0a498703fbf463e0d&query=3&select2=resource%3A%2F%2Fgre%2Fmodules%2FUITelemetry.jsm

and you will see the last drop down on the page to be empty- this makes it hard to know what source/test file you are querying on.

If using thread.js, then it will be simpler to add it as a script to the HEAD of each *.html file:

<script type="application/javascript" src="modevlib/threads/thread.js"></script>

Remove instances of

importScript(['modevlib/main.js'], function () {

The modevlib library is a collection of smaller libraries for building charting dashboards. It copies the import.js[1] and thread.js[2] source code, which have their own documentation.

[1] https://github.com/klahnakoski/jsImport
[2] https://github.com/mozilla/jsThreads

In addition to just disabling the inputs like right now.

A test directory, containing HTML pages, that verify features can help with debugging modules. Specifically, I could not find the entry point for ccov_api.js that revealed the problem Greg mentioned.

Please make a page that builds a JsonCcov object and attempts to make the problematic call. I can then debug the problem.

when displaying results with relevancy, sort by relevancy (highest -> lowest) and bold the results if they are > 0.7.

Let the user select a source directory. For every file (recursively) in that directory, list the file name along with the code coverage percentage of that file.

I believe the canonical code coverage UI is to show the percentage of lines covered by testing. If it can be done for one, then it can be done for all files, all directories.

Let user select a file. Then, show all the code lines of that file, and highlight the lines covered.

it is hard to know which revision is which, a date goes a long way to help figure out what we are looking at.

for example:
chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/xpinstall/browser_whitelist2.js

should be:
toolkit/mozapps/extensions/test/xpinstall/browser_whitelist2.js

...when the query returns an empty result set

For instance, if I go to http://chinhodado.github.io/codecoverage_presenter/?buildRevision=232db2940e992fe4c998dbb0a498703fbf463e0d&query=3&select2=resource%3A%2F%2Fgre%2Fmodules%2FUITelemetry.jsm I get a great compact list of tests that touch this file. This is really exciting, because I can figure out those are the tests to go to if I'm changing that file.

For many other queries, the list is far too large, for instance Permalink: http://chinhodado.github.io/codecoverage_presenter/?buildRevision=232db2940e992fe4c998dbb0a498703fbf463e0d&query=3&select2=resource%3A%2F%2Fgre%2Fmodules%2FRemoteAddonsParent.jsm

While all those tests probably touch some part of RemoteAddonsParent.jsm, I wonder whether we could "rate" the tests, by sorting, putting them into buckets, or even providing a column on the right that has the corresponding percentage coverage (i.e., this test covers X% of the file you asked about).

Now that we have relevancy data, add this to other queries so we always have this data.