Templater approach to extensibility/robustness

[nick-gorman]

@EllieKallmier Been thinking about your comment in the meeting today regarding templater extensibility/robustness/flexibility to different inputs than expected. Particularly, when reading #114 I noticed how our current approach of testing for different combinations of empty inputs really bloats the test suite. I had thought this was kinda prefered and nice to be consistent with how we expect the translator to behave. But it did strike me that there is another option: we could assert in the templater that inputs are the shape we expect based on v7.5, even if its just non-empty that kind of thing, and then that would remove the need for all those extra tests. I don't think this needs to block #114, but could be worth considering if it would make life easier for the rest of the templater.

[EllieKallmier]

Oh yeah, I'm not against that at all - possibly goes back a bit on our "less defensive" kind of paradigm but for the sake of reducing some of that excess (on the assumption of IASR inputs as-is) I'm down.

Would you envision this assertion happening at the higher-level orchestrator functions (e.g _template_connection_costs) only? Or we could make similar assertions (sparingly) where particular pain points might be - e.g. in functions whose input df(s) are the output of other functions that mutate them (filtering, grouping, merging etc) in such a way that they could end up empty. Or something else entirely!

But yes in general I'm for finding ways to keep the tests more meaningful/concise particularly under the assumption of IASR table inputs.