Better test coverage

[nossleinad]

#45 suggests our coverage is poor. In this case there's probably not a specific @test we want to perform. Rather, there should be a call to that constructor somewhere in the tests (that causes our unit tests to error rather than fail).

[murrellb]

This also suggests our coverage is poor:

Given that we expect to have a proliferation of models, if there are standard default constructors for everything that will set things up with sensible defaults, we can use a similar strategy to Optimisers.jl (https://github.com/FluxML/Optimisers.jl/blob/master/test/rules.jl), and have the tests construct the model with defaults, and simulate over a tree with it. And maybe do a check if inference is allowed (maybe we can have backward! return false for sim-only models, or force all sim only models to share a parent type?) and then do an LL calc from the data the model simmed.

It won't catch everything but it'll be a good way to force things to be more standardized and catch major issues.