Unit Test with Test Data Strategies #596
Brennan1994
started this conversation in
Ideas
Replies: 1 comment
-
|
@Brennan1994 I am sorry I lost track of your discussion. Have we made any movement or do we need to discuss further? You're the pro when it comes to this kind of stuff - I trust your recommendation. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
With some discussion and influence from Alex, I want to lay out a couple options for testing the stage damage compute. The issue is it really requires data. We're at the point in our testing now where we're a little above what is easily unit testable, and we're getting into the grey area of what should be GUI tested, and what can be written into a unit test. The RAS Output files are big, and don't really want to be stored on github. Below are some options:
We already have some Muncie files in the Repo. Let's keep those where they are. They're fine. For testing the full aggregated stage damage compute though, I propose we write up a little readme with a hyperlink to download the whole set of data from a public HEC-Drive Share link though, and force our team to download it somewhere on our machines and run it from there locally. It's not sexy, but it'll mean we don't have to wait for the github build server to download half a gig of data everytime we test. It also avoid GitHub getting pissed at us for doing that. Even if we put that data in a NuGet, we'd still be making that big download everytime.
A little friendlier would be me generating a SUPER SMALL dataset. Like, a flat 2D plane for a terrain, 25grid cell 2D mesh, and a series of nonsense flows that produce varying profiles. Then we could make similary nonesense SI, IAs, Indexes, etc. that go with it.
There's annoying things about hitting disk though with unit tests. For one, it's always slower. Managing this data is annoying, and there's access issues that might come up with tests running parallel, where they might both try to access the same file at the same time and bust for no good reason.
For now, I propose we post the Muncie data on drive and put a download link in a readme. We need to make sure to attribute the tests that go with it specifically so that they don't get run and fail our CI/CD checks. Later we can add a local synthetically small dataset for unit tests, and eventually we can come up with a system to regression test larger models automogically, but I think that's a little cart before the horse right now
Beta Was this translation helpful? Give feedback.
All reactions