Add new features to client-side testing document

[kdahlquist]

The new features that @eileenchoe, @yshin4, and @mihirsamdarshi worked on this semester (and last) need to be added to the client-side testing document.

[dondi]

@dondi and @eileenchoe walked @mihirsamdarshi and @yshin4 through the feature file JSON format located in https://github.com/dondi/GRNsight/tree/master/documents/developer_documents/testing_script_generator and they will start trying their hand at editing this file.

[kdahlquist]

We need to do this, too, so that we can systematically test interactions between features.

[eileenchoe]

Completed for node coloring, and wiki has ben updated. Included in PR #582

[eileenchoe]

All new features have been added to featureList.json and the wiki has been updated accordingly.

[kdahlquist]

I'm going to keep this one open because we will need to work on it during the sprint. We need to add two columns to the GRNsight Function Availability Table on the wiki for "Expression Data Loaded" and "No Expression Data Loaded".

[kdahlquist]

@kdahlquist is working on this now. Upon discussion with @mihirsamdarshi and @johnllopez616, the columns of the function availability table will be "no graph loaded", "unweighted graph/no node coloring", "unweighted graph/node coloring", "weighted graph/no node coloring", "weighted graph/node coloring".

[kdahlquist]

I have finished updating the GRNsight Function Availability Table on the wiki.

I have a question: does the automatic client-side test generator just make the testing protocol or does it also automatically generate the tables in the wiki document? If it does, then what I wrote up directly on the wiki needs to be encoded.

Also, I still need to review the GRNsight Client Side Testing Overview Table (above the other one in the wiki.) Will do this tomorrow.

[kdahlquist]

Worked on the Overview table today. I'm re-organizing it in order of the Drop-down menus because the options are a little scattered right now. Will need to finish tomorrow.

[kdahlquist]

I finished the Overview table doing the following:

• reorganized the table to follow flow of dropdown menus
• expanded a couple of items to encompass all options for toggle button
• numbered the items to keep track of them more easily
• added items regarding left-clicking and right-clicking on nodes, moving graph

I also added the items to the Function availability table.

What I want to do next is give a finer scale to the Function availability table. Right now it has columns for no graph, and the four types of graphs loaded (weighted/unweighted and node color/no node color). There are certain functions that should only be available under other conditions. For example, we don't show the weight display options when an unweighted graph is displayed.

Once these are enumerated, then we will basically have our "state diagram". We will need to make sure the logic is encoded in the actual Client Side Test Generator script. This will also serve as a guide to the state controller.

[kdahlquist]

@dondi will advise @kdahlquist how to edit code and json file to work on this next week.

• tables in wiki are autogenerated by code, so plan will be to alter code, run it, and match it to what @kdahlquist has manually edited on the wiki.
• conditionals need to be written for other dependencies

[dondi]

Green light on file separation—ultimately these files serve the purpose of making it easier to do client-side testing so anything that makes this information easier to manage is worth considering.

We will also go ahead and come up with an ID system that will allow us to reference specific cases succinctly. IDs can also be included in Markdown and as long as they are stable over the lifetime of the use case/JSON then that looks good.

[dondi]

Another next-step would be for @ahmad00m to start auditing some of the test cases to check whether they make sense in the context of latest beta/UI/etc. and to see whether additional logic might need to be applied (e.g., inapplicable sequences, sequences that have no effect, etc.).

[igreen1]

PR #909 addresses this issue with a quick fix for #907 included.

Broke up the featurelist into multiple json files and added simple ids for each feature that can be easily scaled as new features are added/removed. The screenshot below shows the new format of the client side testing document.

If approved, I will add it to the wiki in this format. (I am waiting to be sure the group is okay with ID as its stands and doesn't want a more complicated id system)

[dondi]

Format looks good, as well as the new file structure. Looks like we can proceed with next steps:

• Verify the accuracy/completeness of the features, actions, etc. in the JSON files
• Explore ways to let the user specify which scripts to generate based on feature/IDs
• Generate some test scripts to pilot

[igreen1]

Commit #61eb5ecee2f3e184573d5ec032f143fa9900d4a0 added command line options to allow the user to specify which ids (features) to test.

@igreen1 tested this a few times and it is working. However, it is prone to the same issues of odd language. @igreen1 and @ahmad00m will continue to work on the language used and other improvements to the logic of the testing script

For reference (this is also in the testing-script-generator.js file),
-l followed by a list of ids will create a testing script for those ids
-j <fileName> (fileName is optional, it will default to testFeatures.json) will create a testing script for the ids in the filename (JSON format).
The JSON file should be an array [] of ids

[ahmad00m]

@ahmad00m finished checking the client side testing document. A few bugs and language errors were found. One of the bugs was that the node coloring checkbox in the dropdown menu would not toggle off and it would always remain on. The other bug was found to be related to the viewport size. Even though when the viewport size changed automatically the viewport checkbox in the dropdown menu would always be checked as medium size unless the size was changed manually in the dropdown menu.
One of the language errors was "The viewport should always be contained within the viewport" and @igreen1 suggested to change it to "The graph should always be contained within the viewport" also a similar language error was found in later test which was "The viewport should be allowed to extend past the viewport" and suggested change was to "The graph should be allowed to extend past the viewport".
Also, when node colouring is disabled it is best to describe the result as "... and node coloring toggle button text in sidebar menu should toggle off, Even if expression data sheets are present in input workbook".

[dondi]

The first bug appears to be #906 whose is now on beta for @ahmad00m to review. The second bug may be new and should be turned into an issue.

Other changes are to be expected and part of this on-going process.

[dondi]

As the script generator settles, let's sample some scripts to check for intelligibility/errors and validate some of the sequences. Let's do two samples:

• A set from new features since those haven't been exercised yet
• A set from established features to verify that there have been no regressions

Based on what happens here we can determine next steps.

[igreen1]

• Old established features seem to work as before for testing document.

• New features (Species especially were tested) work as expected. Though they point to deeper issues with the general logic.

Some minor graphics bugs were fixed. Also, there is an issue (though not a bug) in how to represent empty/default values. @ahmad00m has mentioned this before, but another example is the 'click node to display gene information'. How is 'no click' to be represented. If 'no click' performs no actions, and the 'result' is left empty, it creates a minor bug of an extra bullet point. But, adding a phrasing that is clear is difficult. Perhaps someone else had a better a idea than "the gene page should no open" for "no click".

However, there is a deeper issue in the logic, best shown by the following example. Exports cannot work if no graph is loaded. And, the testing script should 'know' this as availability is set to false if no graph loaded for export data. However, it still creates this test.

Second, species commands are redundant. Because dropdown and sidebar are treated as separate features, they can create odd combinations like this. But, if they are treated as the same, bugs like #906 might not be caught. And, the sidebar and dropdown are only mostly identical, there are some differences in their operation.

Test 1

Instructions:

• Load Graph - None
• Dropdown Menu: File -> Export Data - Select "To Unweighted SIF"
• Dropdown Menu: Species -> Current Species - Select a species
• Sidebar Menu: Species -> Current Species - Select a species from a dropdown list
• Viewport Menu: Node - No Click

Results:

• GRNsight should have no graph in the viewport
• GRNsight should export an unweighted SIF file from the graph currently loaded
• Opening gene information pages will use information of the selected species.
• Opening gene information pages will use information of the selected species.

[dondi]

After discussion, a few possibilities emerged: (a) some new features might need updates to the availability property; (b) there is a newer behavior where distinct UI approaches to accomplish the same thing (like in the example above) may need a new flag/marker stating that these UI approaches should be mutually exclusive (i.e., never combined in the same script)

[dondi]

Given the number of new features/pathways involved with the year’s overall work, it remains important to keep the features updated. Even if the number of cases grows significantly, what matters most is the awareness of the new variations in the latest functionality