App::Prove::History

Ovid on 2008-12-09T11:42:52

A new development version of App::Prove::History is available on github. You can check it out with:

git clone git://github.com/Ovid/app--prove--history.git

It depends on the development version of Test::Harness, available at:

svn co http://svn.hexten.net/tapx/trunk test_harness

The schema information is now documented in App::Prove::History::Builder. I've documented all tables (only 3) and what each field stores. If you know TAP::Parser, it should be straightforward. The main table everyone should care about:

  "test_result"
        CREATE TABLE IF NOT EXISTS test_result (
            id           INTEGER PRIMARY KEY,
            suite_id     INTEGER NOT NULL,
            test_name_id INTEGER NOT NULL,
            passed       INTEGER NOT NULL,
            failed       INTEGER NOT NULL,
            todo         INTEGER NOT NULL,
            todo_passed  INTEGER NOT NULL,
            skipped      INTEGER NOT NULL,
            planned      INTEGER NOT NULL,
            tests_run    INTEGER NOT NULL,
            exit         INTEGER NOT NULL,
            wait         INTEGER NOT NULL,
            run_time     REAL    NOT NULL
        );

    * "suite_id"
        A reference to "suite.id"

    * "test_name_id"
        A reference to "test_name.id"

    * "passed"
        The number of tests which passed.

    * "failed"
        The number of tests which failed.

    * "todo"
        The number of TODO tests.

    * "todo_passed"
        The number of TODO tests which unexpectedly succeeded.

    * "skipped"
        The number of tests skipped.

    * "planned"
        The number of tests planned.

    * "tests_run"
        The number of tests run.

    * "exit"
        The exit status of the test.

    * "wait"
        The wait status of the test.

    * "run_time"
        The time in seconds it tooks the test program to run. If Time::HiRes
        is installed, it will have a high resolution time.

I think that my current plan is to only shove this data into an SQLite database and not provide any wrappers or anything for it. If someone wants some DBIx::Class interface or to shove this into MySQL or PostGresql, they can do that separately. This should keep this package lightweight and allow me to focus on getting the data people want rather than supplying all of the bells and whistles.

ANSI?

srezic on 2008-12-09T21:57:11

If you just use standard SQL (whatever this is), then using another DB should just be a matter of changing the DSN, shouldn't it?

Re:ANSI?

Ovid on 2008-12-10T16:34:50

Should be. And I make it easy to provide a different database handle, but that might be for later down the road after I've stabilized a few things :)