search

agl / pond

Pond
BSD 3-Clause "New" or "Revised" License
911 stars 109 forks source link

Remove gtk dependency for client_test.go #149

Closed bnagy closed 9 years ago

bnagy commented 9 years ago

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 commented 9 years ago

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 https://github.com/burdges/pond/commit/b5b959d2d8ccc158176ba01ae28ab9af0eb988d7 so a git cherry-pick b5b959d2d might resolve any immediate issues.

bnagy commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

This https://github.com/agl/pond/pull/165 lets you at least run the tests without gtk.

bnagy commented 9 years ago

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.