Skip to content

Testing Instructions

Jump to bottom Edit New page
everbeek edited this page Oct 12, 2012 · 64 revisions

Part 0: Preamble

Testing Session Goals

Testing URLs

There are these base URLs, used depending on the goal of the test session:

  • Local Dev Testing: http://127.0.0.1:8888/index.html
  • Used if you are working on the project in Eclipse
  • Pre-Deploy Embed Testing: http://bioportal-integration-test.bio-mixer.appspot.com
  • Post-Deploy Embed Testing: http://bioportal.bioontology.org/
  • BioPortal uses the pre-specified http://bioportal-integration.appspot.com to provide the graph visualization functionality. We should test post-deploy via their site, to ensure things work in context, rather than testing using that appspot URL directly. Each release of the embed requires a deployment specifically to "bioportal-integration".
  • Pre-Deploy Demo Testing: http://[version].bio-mixer.appspot.com
  • e.g. http://20120711-1.bio-mixer.appspot.com
  • each time we want to deploy a new demo version, we deploy it with some version number that the app engine uses. This is usually the date of the deployment, possibly followed by a counter number, but it is entirely arbitrary. In the example above, we see "20120711-1" is the version number.
  • Post-Deploy Demo Testing: http://bio-mixer.appspot.com
  • we should not need to test this normally, because in the app engine admin, you deploy to a verison number, test it, and when it is satisfactory, you simply set that version as the default, which will then be accessible from http://bio-mixer.appspot.com.

There are a few forms of URLs, that differ in their arguments or path structure, and also can differ in the base URLs that they can be used with:

  • Full Version Testing (non-embedded)
  • e.g. http://bio-mixer.appspot.com
  • format: [base url]
  • in this form, there is no query parameter string to pass in. (if there is one, it's a secret to me)
  • testing in this case is nice because we don't need to wrangle URLs, but we also need to search and load ontologies and terms manually. The simple search mechanism seems fairly effective, so it's not a drawback,and this search might even be useful for testing the embed formats too.
  • Embed Testing
  • Post-Deploy Embed Testing
    • e.g. http://bioportal.bioontology.org/ontologies/3905/?p=terms&conceptid=SourceCell
    • This base URL has a totally different form overall. Navigating to an ontology or term of interest should be done through the BioPortal site, because this URL form uses the short concept id (as in the above example [frequently or always?]), but it does use the preferred virtual id for the ontology (3905 above)

Converting BioPortal URLs to BioMixer URLs

BioPortal uses many types of URLs, but frequently we will have one that we need covnerted to a BioMixer format, where the "ontology version id" from BioPortal needs to be converted to a "ontology virtual id" for BioMixer. BioMixer deals with concepts all the time, so the BioPortal "short concept id" must be converted to the "full concept id" as well.

In order to get the virtual id of an ontology:

In order to get the concept full id:

  1. go to the bioportal URL, copy the filed seen in the Details tab in the "Full Id" row of the table.
  2. paste that into the following website to encode the URL as a query string:
  1. use that encoded resource URI (url) as the full_concept_id in the BioMixer URL you are constructing

Warning: Be wary of extra spaces in the URL you are encoding! Also, no tool is perfect. Feel free to double check the encoding by doing it manually based on this table: http://www.w3schools.com/tags/ref_urlencode.asp

Example

Older example: Start with an ontology in BioPortal, find the suitable concepts (see goal above), and construct test URLs.

Note that the full concept ID requires encoding [a]. In the above link, http://purl.obolibrary.org/obo/MCS_0000006 becomes http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FMCS_0000006 where:

  • : becomes %3A
  • / becomes %2F

  • becomes %23

[a] For references to URL encoding, see http://www.w3schools.com/tags/ref_urlencode.asp

Browser Coverage

We should test the big four browsers, Safari, Chrome, IE, and Firefox. If sharing testing with someone else, there is no need to overlap on browsers.

Part I - Feature Testing

This set of test goals was created for v.bioportal-integration originally. We should do it generally for test sessions though.

Ontology Coverage for Features

We cannot test all ontologies, but getting coverage of the top five is a possibility. The BioPortal home page has a listing of the top five. Find the virtual id and pick concepts to explore from that list (http://bioportal.bioontology.org/) for all parts of the testing procedure. At the time of writing, the ontologies in question are:

Alternate test ontologies:

These links were given in a previous version of this document...the top 5 ontologies probably trump these. But perhaps these are still of interest:

Items to test:

(1) in the drop down menu, expand random node's concepts, expand random node's mappings & mouse over for popups in each of the following:

  • path to root
  • term neighbourhood
  • mappings neighbourhood

(2) expand nodes using the Concept and Mapping menus that come down from the arrow beneath the node. Explore some.

(3) systematically check/uncheck the options in the Nodes panel

(4) systematically check/uncheck & setting styles in the Arcs panel

(5) test the four layouts in the Layouts panel, which include

  • circle layout
  • horizontal tree layout
  • vertical tree layout
  • force directed layout

(6) try out the Comments panel with some text [not in embed version]

(7) in the Share panel [not in embed version]

  • load the link generated in another browser window
  • test the iFrame in an external website

Part II - Performance Testing

Testing goals for this were originally created for v.20120711-1 & v.20120719-1. We should generally do them for all test sessions. This testing doesn't need thorough ontology coverage, but does require browser coverage.

(1) what to look out for

we need to see if the visualisations are working well in all four types of layout (click on the double triangle sign located at the top right corner to see these layouts), i.e. check if things are slow and whether they freeze when there are too many nodes on a single layout. So it would be good to test nodes that are

  • far from the root,
  • have large sets of children
  • have many mappings.

(2) what needs to be tested

We need to test two things: (i) the embedded version of BioMixer in BioPortal & (ii) the full version of BioMixer.

(2.1) testing the embed

(2.1.1) testing "path to root"

Find an example of a large path to root and put it here.

(2.1.2) testing "term neighbourhood"

Find concepts that have lots of children (i.e. check the tree structure in BioPortal) in order to test "term neighbourhood". (e.g. term neighborhood view for http://bio-mixer.appspot.com/index.html?mode=embed&embed_mode=paths_to_root&virtual_ontology_id=1352&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FNDFRT%2FN0000010584)

(2.1.3) testing "mapping neighbourhood"

Find concepts that have lots of mappings (i.e. check the "Term Mappings" tab in BioPortal) in order to test "mapping neighbourhood". (e.g. http://bio-mixer.appspot.com/index.html?mode=embed&embed_mode=paths_to_root&virtual_ontology_id=1101&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FICD9CM%2F140-239.99)

(2.2) testing the full version

  • full version can be found at the base url (see the section on URLs at the top). For example, we can go to the following URL, which doesn't include the URL parameters for using the embeded mode: http://bio-mixer.appspot.com. It will certainly be at some other version URL for testing purposes though, as discussed in the section about the URL types.

  • Just as when you test the embed (but without having to construct URLs), you'll search for concepts that you know will have lots of children, mappings and far from the root. Drag and drop them onto the Graph view, the check if things are working well.

Add a custom footer
Add a custom sidebar

Clone this wiki locally