Add some helpers for testing to its own package in app #1008
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1008 +/- ##
=======================================
Coverage 20.60% 20.60%
=======================================
Files 193 193
Lines 25237 25237
=======================================
Hits 5199 5199
Misses 19084 19084
Partials 954 954 Continue to review full report at Codecov.
|
| ) | ||
|
|
||
| // TODO: Consider an embedded struct here rather than an interface | ||
| type SuiteI interface { |
| return valAddr | ||
| } | ||
|
|
||
| func BeginNewBlock(suite SuiteI, executeNextEpoch bool) { |
There was a problem hiding this comment.
These consensus-related functions might be better to be methods? Especially if SuiteI becomes a struct
There was a problem hiding this comment.
yeah agreed. Would need to make suite a struct to make it a method (AFAICT, you can't do methods on an interface sadly)
There was a problem hiding this comment.
This is awesome! We should also aim to write more integration tests using these, as imo they provide a "flow test".
Also, I'm planning to write up a follow up issue on doing the same thing for commonly used methods such as LockTokens if you agree?
Also, can we get lint fixed before merge?
|
Any thoughts on struct vs interface? I think interface gives us better composability / more re-usability across codebases, but struct will simplify the code a lot. I'm leaning towards struct, since these whole keeper test suites are kinda odd in that they depend on the OsmosisApp already. I'm generally not a big fan of how they depend on the entirety of the app, but its alright |
|
@mattverse to try a second PR on top of this with the struct approach w/ superfluid, so we can see how we think it compares. |
|
@ValarDragon can I go ahead and merge this? |
* Add some helpers for testing to its own package in app * Fix lint (cherry picked from commit 41a0a0b)
* Add some helpers for testing to its own package in app * Fix lint (cherry picked from commit 41a0a0b) Co-authored-by: Dev Ojha <[email protected]>
Description
Adds some helpers for testing various functions in a re-usable way in app.go
I think this should probably be paired with more custom functions / integrations in modules, to get a more composable testing framework. This at least does a first step with setting up validators, and epochs across modules.
I am torn on whether it should be suiteI, or an embeddable struct though. I'm leaning towards making it an embeddable struct.
For contributor use:
docs/) or specification (x/<module>/spec/)Unreleasedsection inCHANGELOG.mdFiles changedin the Github PR explorer