Add views to aggregate daily allocations and usage by area

[vimto]

No description provided.

[vimto]

@smozely I've started writing some tests for the view in this style. Feels like they could quickly get verbose without some helpers for generating sets of test data. This test data needs to be dynamic, since the new views generate data relative to now.

Any thoughts on things in the Java/Kotlin/Spring ecosystem to help with this?

[smozely]

Ah ... not sure I have any great answers

We had the same kinda thing when trying to test complex views at ECAN, we had written a small JS layer to do similar to this style of testing, we did struggle with how to express in the code what the test data means as it was difficult to jump from "these rows here, mean this output in the view" ... not sure any suggestion here really helps with that.

via DBT we did have an a way of testing constituent views in stages, well actually it was less than perfect in that we could only test the views in stages, not the whole chain together.

Keeping it kinda how you've got there Kotlin lets you add parameters with defaults, and you can pass named parameters. Which would kinda give you the equivalent of passing an object in JS and then it being merged with a default object.

  fun createTestData(
      measurementName: String = "Water Meter Reading",
      consentAreaId: String = "area-id",
      consentSourceId: String = "source-id"
  ) {

/// STUFF

Which can then be called like

createTestData(consentSourceId = "foo", measurementName = "bar")

I think that is a good way to keep the same core test data setup but let you customize it per test

And then for the dates stuff, using the date LocalDate.now().atStartOfDay().minusDays(10) to make everything relative to now ... its kinda ugly because its hard to keep that date mangling noise down.

• Maybe there could be the equivalent of createTestData something like createExpectedResult that would help encapsulate the logic in code, in a way that you can then use SELECT * FROM water_allocation_and_usage_by_area and compare directly to that? ... it might mean each test is doing more work, but keeps some consistency of how they flow

• Some of this would be a bit easier if we had objects that were being returned from the view queries, just because it would be easier to create those than the Map rows to assert against. But that might be overkill if they are only going to be used for tests.

[smozely]

lgtm, with that single nit that you can do or not