Karya, built on Mon Jul 24 11:39:07 PDT 2017 (patch 33511aca01257b76b88de7c7a2763b7a965c084e)

Cmd.ResponderTest

Contents

Description

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?

Synopsis

# States

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

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

# Result

data Result Source #

Constructors

 Result Fieldsresult_msg :: Msg.MsgMsg that gave rise to this Result.result_cmd :: CmdTest.Result Cmd.StatusIn CmdTest, Result has MIDI from the thru mechanism, and updates collected during the event. But responder tests scope over the entire respond cycle, so MIDI potentially also includes play output and updates include diff output.result_updates :: [Update.DisplayUpdate]These are the updates emitted to the UI. The CmdTest.Result updates are those collected during the cmd.result_loopback :: Chan.Chan Msg.Msg result_time :: SecondsCPU seconds it took for this Result to come back. This doesn't include waiting for the Msg.

Instances

 # MethodsformatList :: [Result] -> Doc Source #

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

Print Results and anything interesting in them.

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.

# run

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

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.