Find out how to test interactive UI

[untitaker]

We currently don't test anything from the interactive UI because it's too hard. But it would be interesting what testing would look like. See #94 for a very recent example of where this became a problem

[WhyNotHugo]

My best idea so far is to implement a dummy Screen, and test against that (with some help from mock, probably).

See here for more relevant documentation.

[untitaker]

I had hoped that there already is a testing framework/library for urwid. This is why I tagged this as lv: hard, because eventually we'd need to come up with our own.

[untitaker]

Also whatever we come up with should ideally be reusable outside of todoman, particularly khal.

[WhyNotHugo]

So here's what I'm thinking right now:

• Implement a screen-like class that doesn't do any outputting. I might just subclass that implementation and point output to /dev/null. If this turns out too complex, just write a class from scratch.
• Instances of this class receive a list of keys, that it will simulate were pressed in that order (by returning them via get_input).
• Write a test with a set of key-pressed, and check that the result (in the database) is the expected one, and that no exception were thrown.

This is a very high-level functional test, and not actual unit testing. Unit testing individual components can probably be done some other way.

We don't actually validate that thing look how we want them to, only that they behave how we want them to. The html_fragment display module can do that.

[untitaker]

We'd have to parse the output of html_fragment and compare it to some expected HTML in the tests. Since HTML is a whitespace-insensitive language (and also insensitive against many other things), I suspect that comparing HTML is harder than writing our own display module.

…

On Sat, Feb 18, 2017 at 08:59:59AM -0800, Hugo Osvaldo Barrera wrote: So here's what I'm thinking right now: * Implement a [screen](http://urwid.org/reference/display_modules.html#module-urwid.raw_display)-like class that doesn't do any outputting. I might just subclass that implementation and point `output` to `/dev/null`. If this turns out too complex, just write a class from scratch. * Instances of this class receive a list of keys, that it will simulate were pressed in that order (by returning them via `get_input`). * Write a test with a set of key-pressed, and check that the result (in the database) is the expected one, and that no exception were thrown. This is a very high-level functional test, and not actual unit testing. Unit testing individual components can probably be done some other way. We don't actually validate that thing *look* how we want them to, only that they *behave* how we want them to. The [html_fragment](http://urwid.org/manual/displaymodules.html#screenshot-display-module-html-fragment) display module can do that. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #95 (comment)

[WhyNotHugo]

Maybe we can use/borrow this html comparison assertion code.

Otherwise yes, we could write our own display module based on the HTML one (I'm guessing lots of its logic would be reusable).

[untitaker]

It appears that #170 introduces some sort of UI test. I suspect an easier approach would be to create a fake urwid.MainLoop.