Full test coverage and API documentation

[benlangfeld]

WIP

[benlangfeld]

Going to trim the scope of this to just test coverage and API docs. I want to get that merged ASAP.

[bklang]

Scenario #compile should be renamed #export and take a path at this point

What's the rationale behind this? I think of it as compiling because of the way we have to generate the PCAP to match the XML. But it's really just a language issue. I don't feel strongly about it, but I'm biased against changing it arbitrarily.

Overhaul CLI

I think this refers to making it so you can do sippy_cup run foo vs. sippy_cup -r foo.yml. I'm fine with this change, though I need to understand how you would do both commands in a single execution. There are valid reasons why you might want to compile-only, run-only, or compile-and-run together.

[benlangfeld]

Compiling some PCAP audio and dumping the audio/scenario to disk are two separate concerns. Media#compile is fine, but the purpose of the method on Scenario is to export the scenario and all its components to disk.

As for compile-and-run, executing a scenario would use a temporary location on disk, vs exporting to a permanent location specified by a path. You would never need to do both in one command because the two are separate and independent.

[bklang]

Compiling some PCAP audio and dumping the audio/scenario to disk are two separate concerns. Media#compile is fine, but the purpose of the method on Scenario is to export the scenario and all its components to disk.

But "compiling" for the Scenario also refers to taking the steps and outputting generated XML. To me, compiling is the more appropriate verb for both of those things than exporting.

[bklang]

As for compile-and-run, executing a scenario would use a temporary location on disk, vs exporting to a permanent location specified by a path. You would never need to do both in one command because the two are separate and independent.

One of the use-cases I had envisioned was using sippy_cup to compile a scenario, then hand-edit the scenario, then use sippy_cup to run the now-edited scenario. In an ideal world you would never need to do this, but I think that we are not perfect yet in our capabilities. This would also allow you to run a compiled (and possibly edited) scenario repeatedly without needing to recompile the scenario each time.

👍 as far as using temporary files for running the scenarios if the compiled form is not explicitly requested.

[benlangfeld]

Any chance of a quick review please, @bklang?

[bklang]

Isn't #symbolize_keys redundant with HashWithIndifferentAccess?

[benlangfeld]

Turns out no, but I havn't had time to dig into it.

[bklang]

👍 Looks good, thanks for the cleanup