Better graph behavior for unit test data.

[Chandler Carruth <chandlerc@…>]

Problem

Currently there are several special cases where the graph behaves oddly, often poorly, or is unusable:

• Only one set of unittest data is available.
• Only a very few sets are available, and there were failures in the early sets.
• Unit test data is only available after a certain point in the revision history.

The first case yields a graph which has only a large bar for the failed tests, and an infinitely small (line) bar for the successful tests.

The second case yields 2 "overlapping" bars. A red bar is centered over the first changeset, and the green bar spans the changesets.

The third case simply restricts the graph to the revisions that contain unit test data.

Proposed Solution

Construct the graph as follows. Unit test data, if non-existent for a changeset, is taken to be 0 Total tests, and 0 Failures. First, one special case needs to be handled.

• When the repository has only one changeset, construct the graph as a single stacked bar, red failures at the bottom, green successes at the top.

The remaining cases are handled as follows, letting X be a number of changesets to display, where 2 <= X <= HEAD.

• When HEAD - X is less than some threshold value T, Construct a stacked column graph, with a column for each changeset.
• Else, construct a stacked area graph, with T changesets labeled, evenly distributed throughout the range HEAD - X to HEAD.

This should provide a graph that is always readable and meaningful, and also displays when testing was added to a project that began without a unittesting framework.

[Chandler Carruth <chandlerc@…>]

Changes to charts.py

[Chandler Carruth <chandlerc@…>]

Changes to bitten_config.cs to increase the size. Not strictly necessary.

[Chandler Carruth <chandlerc@…>]

Changes to bitten_chart_coverage.cs - almost a complete re-write.

[Chandler Carruth <chandlerc@…>]

Changes to bitten_chart_tests.cs - almost a complete re-write.