visualize-admin
Testing Forest Fire Warnings dataset
From @rdataflow
Salut Patrick As already announced internally the Forest Fire Warnings are published on PROD daily. Is there a quick yet solid way for you the include this important data in your development tests? i.e. by coloring all the warnings equally https://visualize.admin.ch/de/v/94YsSjb5g88m nb: the data is updated daily so the timestamp and the occurring warning levels are subject to change regularly… Salutations Thomas
Hi @rdataflow, we already had a test for this cube. I am not sure what you envision as part of the testing, what would be important for you to test ?
For me, it is important to have something a bit stable so that at least I can check that some things do not move. Previously, as we had problems concerning the sorting of the ordinal danger ratings dimensions, I had some tests revolving on this, making sure that the table view sorted by danger ratings had the correct order).
Here it seems like the cube is changing daily, and if for some days, there are no particular risk, we cannot conduct the test properly (cannot check that the order of values inside the column is "low danger" / "moderate danger" / "high danger" if suddenly the "high danger" value disappears). I think one way to circumvent this would be to have a date dimension, this way we would 1. be able to test on a particular date and the results would be stable, 2. have the ability to have a view over time when we implement the time slider on the maps.
cc @adintegra
@ptbrowne hmm, as you noted the PROD cube is always moving forwards. while data structure is stable, the values will change frequently. time only figures as annotation, not as key. no such dimension will be introduced according to the data provider.
one way I could think of to mitigate such changes in the tests would be to mock the values or even the entires SPARQL responses and only update the mocked input occasionally i.e. in case GraphQL changes its SPARQL queries...
or would it be easier to define some visual regions where changes are allowed?
cc @adintegra
I can perfectly mock out the graphql queries to make sure it is stable, in the test. Would that be sufficient for you ? I thought it would be important for you to test out that the "real" data is correct.
while monitoring of the real data certainly also is an important task we definitely need
I guess the role of the ci tests is more to ensure you don't by accident break this chart.
nb: would you preferably mock the SPARQL output (which is the GraphQL input) and thus test GraphQL+app or would you mock the GraphQL output for the app (which only would cover the app itself)?
I guess the role of the ci tests is more to ensure you don't by accident break this chart.
For sure, agreed, but it would not guard you from breaking the chart by changing the structure of the data.
time only figures as annotation, not as key. no such dimension will be introduced according to the data provider.
I am curious, do you have more information on why this is the case, and why this choice was made ?
nb: would you preferably mock the SPARQL output (which is the GraphQL input) and thus test GraphQL+app
The app is changing more than the graphql endpoint, and we have had very few problems on the GraphQL layer. I already have a method to mock out easily the data that the browser receives, so I would only mock the GraphQL output.
decision was to only make available latest data. same data is also avail on https://map.geo.admin.ch/?layers=ch.bafu.gefahren-waldbrand_warnung