test(x/twap): `afterCreatePool` function

[p0mvn]

Background

We should add direct unit tests for: https://github.com/osmosis-labs/osmosis/blob/204652abb66009107cdf904628ee224bcbc911ff/x/twap/logic.go#L71

Acceptance Criteria

• unit test the function
• reuse existing test utilities and test TWAP records where possible

[ValarDragon]

Wait why? We have a test that creates a pool and asserts the equivalent desired behavior seems fine?

A second test for just the method feels like extra boilerplate, for hooks that are just pass through. Testing the wiring feels preferrable?

[p0mvn]

I agree that the test we have covers most of the logic we want. However, it's a functional test rather than a unit test. It is useful to have both. With the functional, we can see that different system components work as intended i.e. we create pool -> AfterCreatePool hook gets triggered which calls the afterCreatePool function. On the other hand, a direct test for afterCreatePool tests this single unit of computation in isolation.

Since there are several behaviors and code branches in afterCreatePool function, having a direct test is valuable.

Initially, I didn't find the functional test by following references due to afterCreatePool function being hidden under hook creation logic.

So from the dev UX standpoint, having a direct test for afterCreatePool to enable the ability to step through the method and observe the behavior of its callees, is helpful.

[mattverse]

I think it's in the border of unit test vs integration test, where the existing test looks closer to integration test. I do generally feel fine with having a direct functional test for this