-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(core): remove legacy "02" tests #3677
Conversation
a53def1
to
b1cdbf8
Compare
ee462a0
to
bb10581
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, just minor comments/changes
core/api/test/legacy-integration/app/trigger/trigger.fn.spec.ts
Outdated
Show resolved
Hide resolved
paymentRequest, | ||
} | ||
|
||
it("persists payment to be deleted in ln-payments collection", async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not a test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you mean? There's a code branch in checkAndDeletePaymentForHash
that persists an lnPayment if it didn't previously exist in LnPaymentsRepository that I explicitly wanted to test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I review bottom -> up, there is no need to have 2 tests for this, is just add
const lnPaymentAfter = await lnPayments.findByPaymentHash(paymentHash)
if (lnPaymentAfter instanceof Error) throw lnPaymentAfter
expect(lnPaymentAfter.paymentHash).toBe(paymentHash)
in second test but it is up to you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to have them separate because the 2nd test needs to have an explicit step that marks isCompleteRecord
as true and I bring that in manually, and if I tried to not do that then the test becomes more complicated because later tests would rely on prior state in the test
await lnPayments.persistNew({ | ||
paymentRequest, | ||
paymentHash, | ||
sentFromPubkey: DEFAULT_PUBKEY, | ||
}) | ||
await lnPayments.update({ | ||
paymentHash, | ||
isCompleteRecord: true, | ||
} as PersistedLnPaymentLookup) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is what needs to be tested... deleteLnPaymentsBefore should persist it in lnpayment if it does not exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I don't understand 😅 ... isn't that what this tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this not done by await Lightning.deleteLnPaymentsBefore(timestamp2Months)
line 89?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nope, it persists it but then it won't get isCompleteRecord
property marked as true
unless we run updateLnPayments
which is a lot more than we need just to test that deletePaymentByHash
gets hit under the right conditions
So I just manually setup the lnPayment in the repository so that the use-case can continue on to what we want to test here
@@ -104,6 +122,9 @@ describe("onchainBlockEventHandler", () => { | |||
let lastHeight = initialBlock | |||
const subBlocks = subscribeToBlocks({ lnd: lnd1 }) | |||
subBlocks.on("block", async ({ height }: { height: number }) => { | |||
// this sleep seems necessary to allow confirmations to propagate for | |||
// 'getChainTransactions' call inside 'listIncomingOnChainTransactions' | |||
await sleep(500) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then is something else.... please dont use this inside the handler (we dont have this in trigger handler)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok removed here, will troubleshoot again when we're actually removing 01
folder be614f5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh actually, we already have this test in bats #3710
be614f5
to
ef1e61b
Compare
No description provided.