Karya, built on 2018-02-23T20:23:55 (patch cf8565b7ac832266878af99a942555d139065f12)

Safe HaskellNone




This is similar in intent to Cmd.CmdTest, but it simulates the entire respond loop. So it's more accurate and can test more, but is less convenient in that you can't run Cmds directly (you have to use respond_cmd). In addition, you can't run the tests from ghci since it winds up linking in the GUI libs, even though there's no GUI.

TODO shouldn't it be possible to lift this restriction?



mkstates :: [UiTest.TrackSpec] -> States Source #

Make a UI state with one block with the given tracks, and a standard cmd state.

mk_cmd_state :: Ui.State -> ViewId -> Cmd.State Source #

Many cmds rely on a focused view, and it's easy to forget to add it, so make it mandatory.


data Result Source #




print_results :: [Result] -> IO.IO () Source #

Print Results and anything interesting in them.

result_perf :: Result -> IO.IO (BlockId, Msg.Performance) Source #

Wait for a DeriveComplete and get the performance from it.

This is error-prone because if you call this on a Result that didn't regenerate the performance this will hang until read_msg gives up.


respond_cmd :: States -> Cmd.CmdT IO.IO a -> IO.IO Result Source #

Respond to a single Cmd. This can be used to test cmds in the full responder context without having to fiddle around with keymaps.

respond_all :: Thread.Seconds -> States -> Cmd.CmdT IO.IO a -> IO.IO [Result] Source #

Continue feeding loopback msgs into the responder until I see DeriveCompletes for all the blocks I expect to derive.

This is a hack, because I want to make sure all msgs have been processed, but there's no explicit way for the system to say it's done. But since the only thing chucking things in loopback is background derivation, I can use what I know of how it works to guess when it's done.

It's dangerous to look for a particular DeriveComplete because the order in which derive threads complete is non-deterministic.