View source for User:Ctalbert/ValgrindUnitTestUI

__NOTOC__

So I took this back to a really simple design.  My principles are that the basic unit of information here and the most valuable information are the messages themselves.  The second most valuable piece of information are the bug numbers that each message is affiliated with and the third is the test and the code location of the message.  I want to use our existing systems as much as possible and take advantage of the browser for viewing the items in a side-by-side format.

So, the first screen you'd see would be Heather's title bar for some UI prettiness, and then beneath that you'd have:
<pre>
---------------------------------------------------------------------
| Firefox Crash & Unit Testing                                      |
|                                                                   |
|-------------------------------------------------------------------|
|                                                                   |
| | Repro'd Crashes | <Assertions> | Valgrind/Purify Msgs | Tests   |
| ______________________________________________________________    |
| |                                                             |   |
| | Message        | Date      | Build Ver  | OS  | Consistency |   |
| |--------------------------------------------------------------   |
| | this is an asse|2010-01-22 | 1.9.3      | lin | 100%       |    |
| | rtion msg      |-2010-02-01|            |     |            |    |
---------------------------------------------------------------------

</pre>

So here you can see the basic idea.  A table of the text of the assertion or valgrind message, failing unit test or the crash signature ( you pick which one by the links at the top of the table.)  And then the table shows you last date the message occured on, build version, the OS(s) that it happened on and the number of times that it has been seen.  

So for each clicked item on top you'd get a similar table:
* Repro'd Crashes
** Message - Crash Signature 
** Date - date reproduced on
** build ver - version of gecko/firefox reproduced on
** OS - os's reproduced on
** frequency/consistency - ratio of number of times it was reproduced over number of crashes in batch. (or we might want to replace that with associated bug id and have the ability to file a bug on that crash if need be from there because this measure will always be pretty low given crash URL volume.
** Additional column - we might want to link over to crash stat-s if we can find a reference of that crash in that system.
'''IMPL NOTES:'''crashes from crashtestdb/crashes

* Assertions & Valgrind messages use the same table format:
** Message - assertion message
** date - the first seen date to the last seen date (so a date range)
** build ver - version it was seen on
** os - os it was seen on
** frequency/consistency - ratio of runs with this message to total number of runs.  We might also want a frequency column to show total number of times we hit this message as well. But I think the consistency is a more important number if you are looking to debug it.
'''IMPL NOTES''': use unittest/assertions document for this and valgrind document for the data

* Tests - show the failing tests that are throwing these messages
** Message - the name of the test
** date - first failure to most recent failure ( a range)
** build ver - build versions it fails on
** OS - os's it fails on
** consistency - ratio of number of times it has failed to number of runs.

= Interactivity =
So, each table has a link on the message text.  If you click on that link different things happen depending on what view you are looking at.  In all cases you get a little panel over your table that provides you with a couple of options, kind of context-menu-ish.

== Crash View ==
Click on a crash signature you get:
* Show full stack (goes to a page that shows full stack for crash, along with any associated assertion messages from that crash.)
* Show possibly related bugs (opens these bugs in tabs)
* Show in crash-stats (if we found a match in crash-stats, opens crash-stat view for this signature in a tab)
* File bug on this crash (uses Heather's file a bug code she's already written but includes the full stack in the bug)

== Assertion/Valgrind view ==
Click on an Assertion/Valgrind message you get:
* See associated bug data for this message (takes you to a page with a simple table that shows the open and closed bugs for the given message.  From that page you have the option to open each bug individually in a tab (by clicking the bug id) or you can click the two buttons on that page that will open all the "open bugs" in a st of tabs or the "closed bugs" in a set of tabs.  Something like:
<pre>
--------------------------------------------------------------------
| Bug data for Assertion "Kowabunga and slop the chickens!"        |
|                                                                  |
| _________________________________________________________________|
| | Open Bugs:  | <34354> <34345> <555848>       | Open all in tabs|
| | Closed Bugs:| <45634> <34545> <234343>       | Open all in tabs|
|------------------------------------------------------------------- 
</pre>
Each bug is linked, and if clicked on will open in a new tab.  Or they can click the "open all" button and open all that set of bugs in a new set of tabs. TODO: Or would it be better to open them all in a bugzilla search view of those bugs so that they could then see a clear summary of the bugs.  I think I like that better.  So that if you click the "open all" button you get something like [https://bugzilla.mozilla.org/buglist.cgi?bug_id=334546%2C523123%2C443523;bugidtype=include;resolution=FIXED;resolution=INVALID;resolution=WONTFIX;resolution=DUPLICATE;resolution=WORKSFORME;resolution=INCOMPLETE;resolution=EXPIRED;resolution=MOVED;resolution=---;query_format=advanced this].
* See associated tests that exposed this message - this would take you to a table showing the tests and the build version and the operating system that caused this assertion/valgrind message to occur.  From here, the test name would be an MXR link to that code file.
* See the source file for this message - I think we can do this with an mxr query as well even though we don't know the line number.  At the very least we can provide a link to the file.  At best we might be able to do some query parameter magic to direct right at the assertion, but in my quick testing I don't see a simple way to do it.  But at least if we open the file for them it's a quick CTRL+F search for the assertion text.

== Test View ==
Click on a test name and you get:
* Open this test in MXR
* See bugs associated with this test - we'll just show them the results of a bugzilla search page by searching for this test name in the comments field of a bug, very simple, but sometimes necessary to track these things down.
* And see all assertions/valgrind messages associated with this test - if they click on this one, then they get a combination table with assertion and valgrind messages that are only caused by this test.  The format of the table would be the same as the entry-view format of the table, except this one would include both assertion and valgrind messages.  If you clicked on the name of those assertion/valgrind messages you would be presented with the same options as above when you are looking at a main table of assertion or valgrind messages.