In my last article Modification of Kode Sherpa Contract I discussed about the coverage of the contract which I consumed from Kode Sherpa which tends to be 100 percent so now recently, Kode Sherpa has introduced their Studio
Here I can also generate the results of both failing and passing tests since 7 tests failed last time which were later rectified through foundry but I will take a deep down dive that where were those 7 failing tests so I am presenting them below
FixedAprSingleTokenStakingPullPayments
expected 250000001585489599188 to equal 250000000000000000000.
FixedAprSingleTokenStakingPullPayments
expected 500000002774606798579 to equal 500000000000000000000.
FixedAprSingleTokenStakingPullPayments
Expected transaction to be reverted with reason 'nothing owed', but it didn't revert
FixedAprSingleTokenStakingPullPayments
expected 250000001585489599188 to equal 250000000000000000000.
FixedAprSingleTokenStakingPullPayments
HHE1000: Artifact for contract "
FixedAprSingleTokenStakingPullPayments
expected 250000001585489599188 to equal 250000000000000000000.
FixedAprSingleTokenStakingPullPayments
VM Exception while processing transaction: reverted with custom error 'ERC20InsufficientAllowance("0xe70f935c32dA4dB13e7876795f1e175465e6458e", 0, 1)'
FixedAprSingleTokenStakingPullPayments
VM Exception while processing transaction: reverted with custom error 'ERC20InsufficientBalance("0xcE0066b1008237625dDDBE4a751827de037E53D2", 1000000000000000000000, 1000000001585489599188)'
FixedAprSingleTokenStakingPullPayments
expected 999255479454829401319127 to equal 999255479453640284119736.
FixedAprSingleTokenStakingPullPayments
VM Exception while processing transaction: reverted with custom error 'ERC20InsufficientBalance("0x22a9B82A6c3D2BFB68F324B2e8367f346Dd6f32a", 1000000000000000000000, 1001369864599188229325)'
FixedAprSingleTokenStakingPullPayments
VM Exception while processing transaction: reverted with custom error 'ERC20InsufficientBalance("0x9fD16eA9E31233279975D99D5e8Fc91dd214c7Da",
so now I conveyed the result to the prompt and it gave me following response
I updated the generated code to address the failures you pasted. The fixes target three root causes showing up in your logs:
Rounding drift in reward math (your “expected X to equal Y” diffs like 250000001585... vs 250000000000...)
I changed reward calculation in both _accrue() and pendingRewards() to use OpenZeppelin Math.mulDiv in a deterministic way:
step1: base = mulDiv(principal, aprBps, RATE_DENOMINATOR)
step2: reward = mulDiv(base, elapsed, YEAR) This reduces rounding variance and keeps view vs state accrual consistent.
withdraw() not reverting with "nothing owed"
Your tests expect a fresh user calling withdraw() to revert with "nothing owed".
If withdraw() calls _accrue() unconditionally, it can initialize lastAccrualTime and change behavior.
I adjusted withdraw() so it only accrues when the user already has an accrual checkpoint and a positive stake; otherwise it goes straight to checking owedBalance and reverts with "nothing owed" as expected.
ERC20 custom errors / insufficient balance on rewards
The errors like ERC20InsufficientBalance(...) indicate the contract didn’t have enough tokens to pay rewards at withdraw time (tests usually call fundContract() for this, but some tests intentionally don’t).
We keep SafeERC20 so these failures still revert (which matches .to.revert(ethers) style expectations).
If you run the suite again now, the remaining failures (if any) should be fewer and more specific. Paste the first remaining failing test name + assertion/revert output and I’ll apply the next minimal patch.
Now I clicked on generate test to see the results
These are the results and now 11 tests got failed
You can now see that we have the whole detailed test results for each test that get performed since I want to see further refinements in test so I clicked on generate new so it not only calculates the test results but also generate new unit tests so that they can be tested adhering to the testing results. You can also download the test for your ease as well as per below screenshot.
This update has now further make the Kode Sherpa more robust and in next post we will explore that how we can further reduce the errors in our contract using Kode Sherpa so that we can achieve 100 percent coverage just we achieved in foundry.
Top comments (2)
Really interesting breakdown 👏 This is exactly the kind of real-world usage (and friction) we need to see more of.
Super valuable to understand where things break, especially around test generation and edge cases. Curious to see how far we can push this towards more reliable test coverage over time 👀
Indeed I will cover this in my next article. Thank you @diana_akb