Feature/scaled testing #878
Conversation
cwms-data-api/src/test/java/cwms/cda/api/location/kind/GateChangeStressTest.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| @Test | ||
| void stress_test() { |
There was a problem hiding this comment.
Is there a better word than stress here? When I saw that immediately thought "parallel" not bulk data.
There was a problem hiding this comment.
should be scaled, sorry
There was a problem hiding this comment.
Honestly that seems even more like something that should be parallel.
But yeah, that seems reasonable. Or at least as reasonable as the english language allows. Perhaps someone else will come up with something.
| import static org.hamcrest.Matchers.is; | ||
| import static org.junit.jupiter.api.Assertions.*; | ||
|
|
||
| class GateChangeScaleTest extends BaseOutletDaoIT { |
There was a problem hiding this comment.
Disable the test, so it's not run in automation
There was a problem hiding this comment.
Don't disable the test. use @EnableIfProperty (that might not be exact) so we don't need to change code to run the test when needed.
There was a problem hiding this comment.
Oh, that's a good idea, thank you. Didn't know that was a thing.
This PR contains a scaled integration test that initially stores gate changes for 1 year of 5 minute data for 18 gates. If this data already exists, it does not attempt to store the data, because it's a very time consuming process.
The actual test retrieves data for the entire range, but requests a row limit equal to 2 weeks of data and then logs the length of data and characters it received. This will help us identify if the JSON is too bulky.
Additionally, because the data storage is separated, the unit test will provide timing, and metrics are stored for the actual data retrieval.