Remove gtk dependency for client_test.go

[bnagy]

I kicked it around a bit, but abstract_gui is wired into GTK design as well in the code so it's not a great test model for the cli client.

Is there a simple approach you'd feel happy with?

[burdges]

There is no test harness at all for the CLI yet, but enough serious people are using the CLI, that maybe one will get written eventually.

I just fixed go test for Pond with GTK on Mac OS X and presumably FreeBSD, Linux without TPM, etc. in burdges@b5b959d so a git cherry-pick b5b959d2d might resolve any immediate issues.

[bnagy]

I'm proposing a test layer that works for the GUI, cli and the daemonised client version I've written. The issue is to try and get consensus about an approach before I write a bunch of code that will never get mainlined.

[burdges]

I've no opinion really but this seems worth highlighting :

Those uiState* messages sent by the GUI for test routines should mostly make sense from the CLI too. If someone added appropriate uiState* information to the CLI, like 25-60 calls, then they could isolate all the testing lines that actually create GTK events into separate methods of TestClient, which they actually implement in a guiTestClient subclass. And another cliTestClient subclass could reimplement these methods for the CLI.

It's not particularly exciting work, but it's much easier than building new tests. And it's a reasonable exercise for someone who wants to become more familiar with the Pond code base, perhaps if some student did a project on Pond.

[bnagy]

This #165 lets you at least run the tests without gtk.

[bnagy]

Looks like #165 was merged, so let's close this for now. I don't feel like it's fully resolved but all the approaches I have mocked up so far which are able to unify the cli / gtk gui and other future guis are too baroque. At least this lets everyone at least share additions / extensions to the core tests.