Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

GEN-1630: increase test coverage #12

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Conversation

fedealconada
Copy link
Contributor

@fedealconada fedealconada commented Nov 8, 2022

  • ignore files on Codecov
  • add tests
  • fix typos
  • add comment on getMaturityBounds

@codecov
Copy link

codecov bot commented Nov 8, 2022

Codecov Report

Merging #12 (aa29a35) into main (b3f33b7) will increase coverage by 12.91%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main      #12       +/-   ##
===========================================
+ Coverage   69.87%   82.79%   +12.91%     
===========================================
  Files           9        8        -1     
  Lines         405      372       -33     
  Branches       66       66               
===========================================
+ Hits          283      308       +25     
+ Misses         98       44       -54     
+ Partials       24       20        -4     
Impacted Files Coverage Δ
src/AutoRoller.sol 92.79% <ø> (+10.16%) ⬆️
src/test/AutoRoller.t.sol 100.00% <ø> (ø)
script/AutoRoller.s.sol
src/external/DateTime.sol 62.00% <0.00%> (+2.00%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@fedealconada fedealconada force-pushed the GEN-1630-more-tests branch 3 times, most recently from 0aa5c0b to 6ced5fd Compare November 9, 2022 14:02
Copy link
Contributor

@jparklev jparklev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverage is awesome – will check back in again tomorrow in case there's any new discussion 👍

README.md Outdated
@@ -22,7 +22,7 @@ Here are some important concepts to understand so you know how the auto-roller w
* `AutoRollerFactory` - on-chain factory for easy deployment of new auto-roller instances.

* `RollerPeriphery` - the slippage protected LP management interface to all AutoRollers.
* `OwnableAdapter` - Sense adapter owned by a unique auto-roller. Through the auto-roller, series rollers can sponsor new series via `AutoRoller.roll` and settle series via `AutoRoller.settle`.
* `OwnableAdapter` - Sense adapter owned by a unique auto-roller. Through the auto-roller, series rollers can sponsor new series via `AutoRoller.roll` and settle series via `AutoRoller.settle`. This adapter must **override** `getMaturityBounds` so only the roller can sponsor preventing a potential DoS attack.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* `OwnableAdapter` - Sense adapter owned by a unique auto-roller. Through the auto-roller, series rollers can sponsor new series via `AutoRoller.roll` and settle series via `AutoRoller.settle`. This adapter must **override** `getMaturityBounds` so only the roller can sponsor preventing a potential DoS attack.
* `OwnableAdapter` - Sense adapter owned by a unique auto-roller. Through the auto-roller, series rollers can sponsor new series via `AutoRoller.roll` and settle series via `AutoRoller.settle`. This adapter must **override** `getMaturityBounds` so only the roller can sponsor, preventing a potential DoS attack.

@@ -369,7 +369,7 @@ contract AutoRoller is ERC4626 {

balances[1 - _pti] = targetToJoin;

if (assets - targetToJoin > 0) { // Assumption: this is false if Space has only Target liquidity.
if (assets - targetToJoin > 0) { // Assumption: this is false if Space has only Target liquidity. TODO: can this ever happen?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps not if we don't allow the pool to be initialized at 0%!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But is this something we should keep just in case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so, not much harm in being safe here besides bloat, but i'll think about it as I continue audit resolutions

vm.stopPrank();

(, bytes32[] memory writes) = vm.accesses(address(autoRoller));
// Check that no storage slots were written to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Check that no storage slots were written to
// Check that the expected number of storage slots were written to


function testAfterDepositWithOnlyTargetLiquidity() public {
// The idea is making a test that covers line case on the `afterDeposit` function
// where `if (assets - targetToJoin > 0)` is false.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true, because even if we have someone try to buy all of the PTs out of the pool, I don't think it's possible to get it down to true 0 after initialization

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect, I'll remove all this

autoRoller.deposit(0.2e18, address(this));
assertEq(autoRoller.balanceOf(address(this)), 0.2e18);

// 3. Roll the Target into the first Series.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 3. Roll the Target into the first Series.
// 2. Roll the Target into the first Series.


// 5. Redeem all shares while still in the active phase.
uint256 targetBalPre = target.balanceOf(address(this));
vm.expectCall(address(periphery), abi.encodeWithSelector(periphery.swapYTsForTarget.selector));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice check here 👌

vm.expectCall(address(periphery), abi.encodeWithSelector(periphery.swapYTsForTarget.selector));
autoRoller.redeem(autoRoller.balanceOf(address(this)), address(this), address(this));
uint256 targetBalPost = target.balanceOf(address(this));
// assertRelApproxEq(targetBalPost - targetBalPre, 0.5e18, 0.0001e18 /* 0.01% */); // TODO: what should it be the expected value?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should expect it to be pretty close to "total deposited amount - firstDeposit" (since firstDeposit is kept locked in the contract forever, similar to the min bpt for our space pool). What were you seeing here for this val?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yeah, i was seeing something similar (I forgot to consider the firstDeposit) but now, considering the firstDeposit:

  • I have deposited in total 0.5e18 and I'm asserting that 0.5e18 - 0.01e18 (total deposited - firstDeposit) should almost equal to the target I received back which is 499642339889372330, shouldn't that be lower? Or how do I establish which is a good delta in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh yea, after you roll the math starts to get a little more complicated I think. You can always do a previewRedeem here to see what it should be out, or you can walk through the trace to see what it's doing. I might do the latter today or tomorrow just out of curiosity


vm.warp(autoRoller.maturity());

// 4. Increase scale and settle the first Series.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we want to manually increase scale somewhere here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no no, it's not needed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not? 😅


// 6. Assert max redeem is same as TODO.
sharesOut = autoRoller.maxRedeem(address(this));
// assertEq(sharesOut, TODO);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think we could do assertEq(autoRoller.maxRedeem(address(this)), sharesOut); again here perhaps?

Copy link
Contributor Author

@fedealconada fedealconada Nov 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, it works :), i would have sworn i tried that and was not working 🤔 and that;s why i was confused

kind: BalancerVault.SwapKind.GIVEN_IN,
assetIn: address(pt),
assetOut: address(autoRoller.asset()),
amount: 0.01e18, // TODO: how do I calculate a number such that it would make the maxPTSale >= diff? This number works though
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, the only case where this isn't true IIRC is if order we'd have to swap here such that the pool becomes very close to the maxRate value (time shifted) so that the user can't safely make the PT in swap needed to withdraw their position without exceeding the max rate

Note that you can check the rate "(pt reserves + total supply / (target reserve * scale))"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants