Include GUI tests in CI testing

[rhwood]

Travis-CI supports GUI testing, so leverage it during CI testing.

[bobjacobsen]

#215 may fix the last two.

[rhwood]

Running AllTest runs into a timing issue on Travis-CI:

• Travis-CI kills processes that run from 10 minutes or more without any output
• AllTest provides no output until all tests are run, at which point it prints a summary and dumps its output
• AllTest can take more than 10 minutes to run

Is there any way to change AllTest's behavior to print its summary at the end of the log, and to provide running output, to prevent Travis-CI from killing it?

I am currently using a special travis-wait command to extend the Travis-CI timeout to 20 minutes, but would prefer not to if possible.

[bobjacobsen]

The junit.textui.TestRunner always caches its stdout away for replay (and sometimes processing) at the end. If we want output to the real (not cached) stdout, we could create our own TestRunner implementation based on copying junit.textui.TestRunner. Unfortunately, it's not just a matter of subclassing, because junit.textui.TestRunner uses a bunch of statics.

[rhwood]

Would this be doable if upgraded to JUnit 4?

[bobjacobsen]

Would this be doable if upgraded to JUnit 4?

I don't know. I've never actually done a JUnit 3 to 4 migration, but I've heard that they involve some rework. Not sure how extensive it would actually be on our code, which has a pretty regular structure.

http://stackoverflow.com/questions/264680/best-way-to-automagically-migrate-tests-from-junit-3-to-junit-4

When (not if) we migrate, we should probably also rethink how we use TestSuite to organize a test hierarchy. Might be right, might not be.