Remove gtk dependency for client_test.go
bnagy opened this issue · comments
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?
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.
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.
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.
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.