Closed ValuedMammal closed 3 weeks ago
Totals | |
---|---|
Change from base Build 9558989002: | -0.04% |
Covered Lines: | 1056 |
Relevant Lines: | 1207 |
Totals | |
---|---|
Change from base Build 9558989002: | -0.05% |
Covered Lines: | 1055 |
Relevant Lines: | 1206 |
@ValuedMammal this looks good but could you add a simple test as above but also that hits this new None
case?
I added to the existing feerate_parsing
test which tests the logic in convert_fee_rate
. I'm not sure if you're suggesting to add another test? @notmandatory @oleonardolima
I added to the existing
feerate_parsing
test which tests the logic inconvert_fee_rate
. I'm not sure if you're suggesting to add another test? @notmandatory @oleonardolima
Oh sorry I didn't look closely enough at the change you made to that test, that covers it.
I added to the existing
feerate_parsing
test which tests the logic inconvert_fee_rate
. I'm not sure if you're suggesting to add another test? @notmandatory @oleonardolima
Awesome, thanks! You covered the simple test I had in mind in ec5ee82
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Totals | |
---|---|
Change from base Build 9558989002: | 0.0% |
Covered Lines: | 1060 |
Relevant Lines: | 1211 |
Change
convert_fee_rate
to returnOption<f32>
instead of Result.PR #65 made this function effectively infallible by removing the parse int error while falling back to a bogus 1.0 feerate if a value isn't found in fee estimates. We could make it return an error if for example the given fee estimates map is empty without changing the function signature but in that case we would need a new
Error
variant making it a breaking change anyway, therefore just change the function to returnOption
which should only beNone
if given a target of 0 or an empty map assuming esplora always has a fee estimate for a target of 1 confirmation.fixes #80