Presented by
Advisor
Problem and goals
Solution strategy
Taxonomy
BackViz design
Implementation detail
Obtained results
Conclusions and future work
Lack of techniques for testing information visualizations that are able to deal with visualizations complexity.
Basic interactions
Are there any areas of current software testing research and techniques that adequately address the needs for data visualization testing?
Software Engineering Institute's taxonomy
Are there any areas of current software testing research and techniques that adequately address the needs for data visualization testing?
How can a data visualization developer develop automated tests that cover visualization interactions and without excessive effort?
Run some tests on the site.
Take screenshots of interactions/components.
Compare those screenshots against a baseline and report differences.
How can a data visualization developer develop automated tests that cover visualization interactions and without excessive effort?
Channel
Mark
How can a data visualization developer develop automated tests that cover visualization interactions and without excessive effort?
Solution strategy
Some steps from a mapping study were used to combine with systematic review
Every element it's in the same position, with the same length and if it's working according to the behavior expected in the code.
Detect if ...
Something was change related to essential concepts in visual analytics, like channel and marks linked to an interaction, e.g:
If when the user is hovering over some element and this one is red instead of blue (supposing blue was the style defined at the beginning).
Also, detecting if a filter is failing using the same data, maybe due to a new change, ignoring some datum. This is the strategy with more sense in the project case.
Taxonomy
7 categories
200 testing types
BackViz design
BDD module
VRT module
Writing tests
Interpreter
Execute
Headless Browser (Execute DOM interactions
Image comparator
Report
Percy
Cucumber understands the language Gherkin. It is a Business Readable, Domain Specific Language that lets you describe software's behavior.
Gherkin serves two purposes — documentation and automated tests.
Feature: Barchart
Scenario: Hover a bar
Given I have my app "http://localhost:7000/"
And I have ".bar" class
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
When I "hover"
Then I check "color"
Scenario: Check all data
Given I have my app "http://localhost:7000/"
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
Then I check "all"
Feature: Scatterplot
Scenario: Click a dot
Given I have my app "http://localhost:8000/"
And I have ".dot" class
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
When I "hover"
Then I check "embeded"
Scenario: Check all data
Given I have my app "http://localhost:8000/"
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
Then I check "all"
Without changes
Color changes
// setup fill color
var cValue = function(d) { return d.Manufacturer;},
color = d3.scale.category20();
Shape changes
"misMatchThreshold" : 0.1,
"requireSameDimensions": true
Less data
Feature: Tree
Scenario: Drag a node
Given I have my app "http://localhost:8000/"
And I have ".nodeCircle" class
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
When I "drag"
Then I check "position"
Scenario: Click a node
Given I have my app "http://localhost:8000/"
And I have ".nodeCircle" class
And I have some devices
| label | width | height |
| phone | 320 | 480 |
| tablet | 1024 | 768 |
When I "click"
Then I check "expand"
Click
Drag and drop
pkill -f "(chrome)?(--headless)"
Drag and drop implementation
//Llamamos a la libreria de casper
var casper = require("casper").create({
viewportSize: {
width: 1024,
height: 768
}
});
casper.start('http://localhost:9000', function() {
this.wait(2000);
this.capture('before.png');
this.mouse.down(400, 550);
this.mouse.move(850, 650);
}).then(function() {
this.mouse.up(910, 700);
}).then(function() {
this.capture('after.png');
});
casper.run();
Slimer
before
after
The complexity of possible test scenarios for visualizations, keeping in mind the universe of interactions and the possibility of combining different idioms, maximizes the importance of the existence of a testing mechanism. For this reason, it is necessary to fully implement the framework that is not part of the scope of this project.
Other possible testing techniques could be applied as would be the static code analysis, to narrow the visualizer scenarios and guarantee that their tests are defined explicitly within what is possible according to the code.
A validation process of the entire library for a diverse set of visualizations is necessary.
Complete Systematic Review could be done, in order to cover all steps and produces a taxonomy more strict in software engineering sense.