Find out how to test interactive UI about todoman HOT 7 OPEN

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

from todoman.

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

from todoman.

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.

from todoman.

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.

from todoman.

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.

from todoman.

from todoman.

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).

from todoman.