refactor: refactor model tests to use a helper function #2965
Conversation
WalkthroughThis update refactors transaction validation tests across a wide range of transaction models in the codebase. The main changes involve replacing direct assertion and validation calls with standardized utility functions ( Changes
Possibly related PRs
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm warn config production Use 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms (7)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the model tests by replacing inline validation calls with helper functions (assertValid and assertInvalid) to improve consistency, while also addressing a couple of minor bugs in the transaction validations.
- Replaced direct validation assertions (assert.doesNotThrow/assert.throws) in tests with helper function calls.
- Updated flag handling in transaction validators to ensure proper conversion (using convertTxFlagsToNumber for NFTokenCreateOffer, and defaulting undefined Flags to 0).
- Fixed a test inconsistency in the DIDDelete tests.
Reviewed Changes
Copilot reviewed 60 out of 60 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/xrpl/test/models/MPTokenIssuanceSet.test.ts | Updated tests to use assertValid and assertInvalid helpers; fixed flag casting. |
| packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts | Refactored validation assertions; adjusted flag type coercion. |
| packages/xrpl/test/models/DIDDelete.test.ts | Refactored test assertions; note potential test description mismatch. |
| packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts | Updated flag conversion to use convertTxFlagsToNumber. |
| packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts & MPTokenIssuanceCreate.ts | Changed flag handling to default undefined Flags to 0. |
| ... (other test and source files) | Similar refactoring and minor bug fixes across multiple transaction tests. |
Comments suppressed due to low confidence (1)
packages/xrpl/test/models/DIDDelete.test.ts:25
- The test case titled 'throws on invalid DIDDelete' is asserting that the transaction is valid using assertValid(tx) even though the description implies that the transaction should fail validation (e.g., when an extra field 'FakeField' is present). Please review whether extra fields are allowed in DIDDelete transactions and update the test description or assertion accordingly.
assertValid(tx)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (30)
packages/xrpl/test/models/oracleDelete.test.ts (1)
28-31: Consider alternative to delete operatorWhile the functionality is correct, consider replacing the
deleteoperator with an assignment toundefinedfor better performance.- delete tx.OracleDocumentID + tx.OracleDocumentID = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCancel.test.ts (1)
35-38: Consider alternatives to the delete operatorStatic analysis has flagged the use of the
deleteoperator which can impact performance.- delete cancel.Owner + cancel.Owner = undefined - delete cancel.OfferSequence + cancel.OfferSequence = undefinedWhile performance isn't typically a concern in test code, using assignment for consistency is preferred.
Also applies to: 41-44
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/ticketCreate.test.ts (1)
29-29: Consider using undefined assignment instead of delete operator.The
deleteoperator can impact performance. Consider using undefined assignment instead.- delete ticketCreate.TicketCount + ticketCreate.TicketCount = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainSet.test.ts (1)
48-48: Consider using undefined assignment instead of delete operator.The
deleteoperator can impact performance. Consider using undefined assignment instead.- delete tx.AcceptedCredentials + tx.AcceptedCredentials = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleSet.test.ts (1)
45-45: Consider using assignment instead of delete for better performance.While not directly related to your current changes, the static analysis tool flagged multiple uses of the
deleteoperator, which can impact performance.- delete tx.OracleDocumentID + tx.OracleDocumentID = undefinedApply similar changes to other instances of the
deleteoperator in this file.Also applies to: 57-57, 114-114, 128-128, 135-135, 142-142, 149-149
🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/trustSet.test.ts (1)
40-40: Consider replacing delete with undefined assignmentThe static analysis tool has flagged the use of the
deleteoperator as a potential performance issue. While this is less critical in test code, consider using undefined assignment instead.-delete trustSet.LimitAmount +trustSet.LimitAmount = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 40-40: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCreate.test.ts (1)
36-36: Consider replacing delete operators with undefined assignmentsThe static analysis tool has flagged multiple uses of the
deleteoperator as potential performance issues. While less critical in test code, consider using undefined assignments instead.// Line 36 -delete escrow.Amount +escrow.Amount = undefined // Line 42 -delete escrow.Destination +escrow.Destination = undefined // Lines 84-85 -delete escrow.CancelAfter -delete escrow.FinishAfter +escrow.CancelAfter = undefined +escrow.FinishAfter = undefined // Lines 94-95 -delete escrow.Condition -delete escrow.FinishAfter +escrow.Condition = undefined +escrow.FinishAfter = undefinedAlso applies to: 42-42, 84-85, 94-95
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (1)
45-45: Consider replacing delete operators with undefined assignmentsThe static analysis tool has flagged multiple uses of the
deleteoperator as potential performance issues. While less critical in test code, consider using undefined assignments instead for better performance.// Line 45 -delete tx.XChainBridge +tx.XChainBridge = undefined // Line 57 -delete tx.SignatureReward +tx.SignatureReward = undefined // Line 75 -delete tx.Destination +tx.Destination = undefined // Line 87 -delete tx.Amount +tx.Amount = undefinedAlso applies to: 57-57, 75-75, 87-87
🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelCreate.test.ts (1)
37-39: Consider using undefined assignment instead of delete operatorThe static analysis tool has flagged the use of the
deleteoperator as potentially impacting performance. While this is likely not a significant concern in test code, for consistency with best practices, consider using undefined assignment instead.- delete channel.CancelAfter - delete channel.DestinationTag - delete channel.SourceTag + channel.CancelAfter = undefined + channel.DestinationTag = undefined + channel.SourceTag = undefinedSimilar changes can be applied to other occurrences of the
deleteoperator.Also applies to: 45-45, 51-51, 57-57, 63-63
🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 38-38: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMVote.test.ts (1)
37-37: Consider using undefined assignment instead of delete operatorThe static analysis tool has flagged the use of the
deleteoperator as potentially impacting performance. While this is likely not a significant concern in test code, for consistency with best practices, consider using undefined assignment instead.- delete vote.Asset + vote.Asset = undefinedSimilar changes can be applied to the other instances of
deletein this file.Also applies to: 49-49, 61-61
🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMCreate.test.ts (1)
36-36: Consider using undefined assignment instead of delete operatorThe static analysis tool has flagged the use of the
deleteoperator as potentially impacting performance. While this is likely not a significant concern in test code, for consistency with best practices, consider using undefined assignment instead.- delete ammCreate.Amount + ammCreate.Amount = undefinedSimilar changes can be applied to the other instances of
deletein this file.Also applies to: 48-48, 60-60
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts (1)
53-53: Consider using assignment to undefined instead of deleteStatic analysis is flagging the use of the
deleteoperator as potentially impacting performance. For test code, this is generally not a concern, but for consistency with best practices you might consider using assignment toundefinedinstead.-delete tx.Amount +tx.Amount = undefinedAlso applies to: 65-65, 83-83, 107-107, 125-125, 137-137, 149-149, 167-167, 179-179
🧰 Tools
🪛 Biome (1.9.4)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateBridge.test.ts (1)
44-44: Consider using assignment to undefined instead of deleteStatic analysis flags the use of
deletefor potential performance issues. While this is a minor concern for test code, you might consider usingundefinedassignment for consistency with best practices:-delete tx.XChainBridge +tx.XChainBridge = undefinedAlso applies to: 56-56
🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/offerCancel.test.ts (1)
47-47: Consider using assignment to undefined instead of deleteStatic analysis flags the use of
deletefor potential performance concerns. For consistency with best practices, consider:-delete offer.OfferSequence +offer.OfferSequence = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 47-47: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDelete.test.ts (1)
37-37: Consider using assignment to undefined instead of delete.The static analysis tool suggests avoiding the
deleteoperator for performance reasons.- delete ammDelete.Asset + ammDelete.Asset = undefined- delete ammDelete.Asset2 + ammDelete.Asset2 = undefinedAlso applies to: 49-49
🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMBid.test.ts (1)
68-68: Consider using assignment to undefined instead of delete.The static analysis tool suggests avoiding the
deleteoperator for performance reasons.- delete bid.Asset + bid.Asset = undefined- delete bid.Asset2 + bid.Asset2 = undefinedAlso applies to: 80-80
🧰 Tools
🪛 Biome (1.9.4)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMClawback.test.ts (1)
45-45: Consider using assignment to undefined instead of delete.The static analysis tool suggests avoiding the
deleteoperator for performance reasons.- delete ammClawback.Amount + ammClawback.Amount = undefined - delete ammClawback.Holder + ammClawback.Holder = undefined - delete ammClawback.Asset + ammClawback.Asset = undefined - delete ammClawback.Asset2 + ammClawback.Asset2 = undefinedAlso applies to: 55-55, 73-73, 91-91
🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/DIDSet.test.ts (1)
52-54: Consider using assignment to undefined instead of delete.The static analysis tool suggests avoiding the
deleteoperator for performance reasons.- delete tx.Data - delete tx.DIDDocument - delete tx.URI + tx.Data = undefined + tx.DIDDocument = undefined + tx.URI = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 52-52: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 54-54: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainClaim.test.ts (1)
44-44: Consider alternative todeleteoperator for better performance.The
deleteoperator can impact performance. Consider using assignment toundefinedinstead:- delete tx.XChainBridge + tx.XChainBridge = undefinedand similar for other properties.
Also applies to: 56-56, 68-68, 86-86
🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDeposit.test.ts (1)
78-78: Consider alternative todeleteoperator for better performance.The
deleteoperator can impact performance. Consider using assignment toundefinedinstead:- delete deposit.Asset + deposit.Asset = undefinedand similar for other properties.
Also applies to: 90-90
🧰 Tools
🪛 Biome (1.9.4)
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelFund.test.ts (1)
33-33: Consider alternatives to the delete operator for better performance.While functional in test code, using the
deleteoperator can impact performance. Consider using assignment toundefinedinstead.- delete channel.Expiration + channel.Expiration = undefinedThis is a minor optimization that's most relevant in performance-critical code. Since this is test code, it's less critical, but it's a good practice to follow.
Also applies to: 39-39, 45-45
🧰 Tools
🪛 Biome (1.9.4)
[error] 33-33: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainDelete.test.ts (1)
31-31: Consider alternative to delete operator for better performance.While appropriate for test code, using the
deleteoperator can impact performance. Consider using assignment toundefinedas an alternative.- delete tx.DomainID + tx.DomainID = undefinedThis is a minor optimization that's less critical in test code, but would align with performance best practices.
🧰 Tools
🪛 Biome (1.9.4)
[error] 31-31: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCommit.test.ts (1)
43-43: Consider using property assignment instead of deleteStatic analysis flagged the use of
deleteoperator which can impact performance. While the impact is negligible in test code, consider using undefined assignment instead for consistency with best practices.- delete tx.XChainBridge + tx.XChainBridge = undefined - delete tx.XChainClaimID + tx.XChainClaimID = undefined - delete tx.Amount + tx.Amount = undefinedAlso applies to: 55-55, 73-73
🧰 Tools
🪛 Biome (1.9.4)
[error] 43-43: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateClaimID.test.ts (1)
44-47: Consider using assignment instead of deleteFor better performance in JavaScript/TypeScript, consider using
undefinedassignment instead of thedeleteoperator.- delete tx.XChainBridge + tx.XChainBridge = undefinedThis applies to all similar test cases in this file.
🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMWithdraw.test.ts (2)
89-90: Consider avoiding the delete operatorStatic analysis tools flag the
deleteoperator as potentially impacting performance.While performance is less critical in test code, consider using undefined assignment instead:
- delete withdraw.Asset + withdraw.Asset = undefined const errorMessage = 'AMMWithdraw: missing field Asset'🧰 Tools
🪛 Biome (1.9.4)
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
101-102: Consider avoiding the delete operatorStatic analysis tools flag the
deleteoperator as potentially impacting performance.While performance is less critical in test code, consider using undefined assignment instead:
- delete withdraw.Asset2 + withdraw.Asset2 = undefined const errorMessage = 'AMMWithdraw: missing field Asset2'🧰 Tools
🪛 Biome (1.9.4)
[error] 101-101: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelClaim.test.ts (2)
36-42: Consider avoiding the delete operatorStatic analysis tools flag the
deleteoperator as potentially impacting performance. While this is less critical in test code, consider using undefined assignments for consistency.- delete channel.Balance - delete channel.Amount - delete channel.Signature - delete channel.PublicKey + channel.Balance = undefined + channel.Amount = undefined + channel.Signature = undefined + channel.PublicKey = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 38-38: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 40-40: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
46-48: Consider avoiding the delete operatorStatic analysis tools flag the
deleteoperator as potentially impacting performance.- delete channel.Channel + channel.Channel = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 46-46: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/payment.test.ts (2)
73-74: Use assignment instead of delete operatorThe
deleteoperator can impact performance. Consider using an undefined assignment instead.- delete payment.Amount + payment.Amount = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
83-84: Use assignment instead of delete operatorThe
deleteoperator can impact performance. Consider using an undefined assignment instead.- delete payment.Destination + payment.Destination = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 83-83: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (60)
packages/xrpl/HISTORY.md(1 hunks)packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts(1 hunks)packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts(1 hunks)packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts(1 hunks)packages/xrpl/test/models/AMMBid.test.ts(5 hunks)packages/xrpl/test/models/AMMClawback.test.ts(2 hunks)packages/xrpl/test/models/AMMCreate.test.ts(2 hunks)packages/xrpl/test/models/AMMDelete.test.ts(2 hunks)packages/xrpl/test/models/AMMDeposit.test.ts(5 hunks)packages/xrpl/test/models/AMMVote.test.ts(2 hunks)packages/xrpl/test/models/AMMWithdraw.test.ts(5 hunks)packages/xrpl/test/models/CredentialAccept.test.ts(2 hunks)packages/xrpl/test/models/CredentialCreate.test.ts(2 hunks)packages/xrpl/test/models/CredentialDelete.test.ts(2 hunks)packages/xrpl/test/models/DIDDelete.test.ts(2 hunks)packages/xrpl/test/models/DIDSet.test.ts(2 hunks)packages/xrpl/test/models/MPTokenAuthorize.test.ts(6 hunks)packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts(9 hunks)packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts(3 hunks)packages/xrpl/test/models/MPTokenIssuanceSet.test.ts(6 hunks)packages/xrpl/test/models/NFTokenAcceptOffer.test.ts(11 hunks)packages/xrpl/test/models/NFTokenBurn.test.ts(3 hunks)packages/xrpl/test/models/NFTokenCancelOffer.test.ts(4 hunks)packages/xrpl/test/models/NFTokenCreateOffer.test.ts(12 hunks)packages/xrpl/test/models/NFTokenMint.test.ts(9 hunks)packages/xrpl/test/models/NFTokenModify.test.ts(5 hunks)packages/xrpl/test/models/XChainAccountCreateCommit.test.ts(2 hunks)packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts(2 hunks)packages/xrpl/test/models/XChainAddClaimAttestation.test.ts(2 hunks)packages/xrpl/test/models/XChainClaim.test.ts(2 hunks)packages/xrpl/test/models/XChainCommit.test.ts(2 hunks)packages/xrpl/test/models/XChainCreateBridge.test.ts(2 hunks)packages/xrpl/test/models/XChainCreateClaimID.test.ts(2 hunks)packages/xrpl/test/models/XChainModifyBridge.test.ts(2 hunks)packages/xrpl/test/models/accountDelete.test.ts(5 hunks)packages/xrpl/test/models/accountSet.test.ts(2 hunks)packages/xrpl/test/models/baseTransaction.test.ts(15 hunks)packages/xrpl/test/models/checkCancel.test.ts(3 hunks)packages/xrpl/test/models/checkCash.test.ts(6 hunks)packages/xrpl/test/models/checkCreate.test.ts(7 hunks)packages/xrpl/test/models/clawback.test.ts(9 hunks)packages/xrpl/test/models/depositPreauth.test.ts(10 hunks)packages/xrpl/test/models/escrowCancel.test.ts(2 hunks)packages/xrpl/test/models/escrowCreate.test.ts(3 hunks)packages/xrpl/test/models/escrowFinish.test.ts(6 hunks)packages/xrpl/test/models/offerCancel.test.ts(2 hunks)packages/xrpl/test/models/offerCreate.test.ts(8 hunks)packages/xrpl/test/models/oracleDelete.test.ts(2 hunks)packages/xrpl/test/models/oracleSet.test.ts(3 hunks)packages/xrpl/test/models/payment.test.ts(5 hunks)packages/xrpl/test/models/paymentChannelClaim.test.ts(3 hunks)packages/xrpl/test/models/paymentChannelCreate.test.ts(2 hunks)packages/xrpl/test/models/paymentChannelFund.test.ts(2 hunks)packages/xrpl/test/models/permissionedDomainDelete.test.ts(2 hunks)packages/xrpl/test/models/permissionedDomainSet.test.ts(2 hunks)packages/xrpl/test/models/setRegularKey.test.ts(2 hunks)packages/xrpl/test/models/signerListSet.test.ts(5 hunks)packages/xrpl/test/models/ticketCreate.test.ts(1 hunks)packages/xrpl/test/models/trustSet.test.ts(2 hunks)packages/xrpl/test/testUtils.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (6)
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/MPTokenAuthorize.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/clawback.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/integration/transactions/clawback.test.ts:165-178
Timestamp: 2024-12-06T19:27:11.147Z
Learning: In the integration tests for `clawback.test.ts`, it's acceptable to use `@ts-expect-error` to bypass type checking when verifying ledger entries, and no additional type safety improvements are needed.
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/AMMClawback.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/integration/transactions/clawback.test.ts:165-178
Timestamp: 2024-12-06T19:27:11.147Z
Learning: In the integration tests for `clawback.test.ts`, it's acceptable to use `@ts-expect-error` to bypass type checking when verifying ledger entries, and no additional type safety improvements are needed.
packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
🧬 Code Graph Analysis (41)
packages/xrpl/test/models/oracleDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/oracleDelete.ts (1)
validateOracleDelete(28-32)
packages/xrpl/test/models/checkCash.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/checkCash.ts (1)
validateCheckCash(40-72)
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceDestroy.ts (1)
validateMPTokenIssuanceDestroy(29-34)
packages/xrpl/test/models/CredentialDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/CredentialDelete.ts (1)
validateCredentialDelete(39-55)
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainAccountCreateCommit.ts (1)
validateXChainAccountCreateCommit(57-69)
packages/xrpl/test/models/permissionedDomainSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/permissionedDomainSet.ts (1)
validatePermissionedDomainSet(33-54)
packages/xrpl/test/models/DIDSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/DIDSet.ts (1)
validateDIDSet(31-49)
packages/xrpl/test/models/XChainCreateBridge.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCreateBridge.ts (1)
validateXChainCreateBridge(48-56)
packages/xrpl/test/models/XChainClaim.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainClaim.ts (1)
validateXChainClaim(63-79)
packages/xrpl/test/models/trustSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/trustSet.ts (1)
validateTrustSet(137-156)
packages/xrpl/test/models/signerListSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/signerListSet.ts (1)
validateSignerListSet(39-88)
packages/xrpl/test/models/MPTokenAuthorize.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenAuthorize.ts (1)
validateMPTokenAuthorize(63-67)
packages/xrpl/test/models/NFTokenBurn.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenBurn.ts (1)
validateNFTokenBurn(48-52)
packages/xrpl/test/models/escrowFinish.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/escrowFinish.ts (1)
validateEscrowFinish(49-81)
packages/xrpl/test/models/checkCancel.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/AMMVote.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMVote.ts (1)
validateAMMVote(39-71)
packages/xrpl/test/models/setRegularKey.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/paymentChannelCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/paymentChannelCreate.ts (1)
validatePaymentChannelCreate(65-106)
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainAddAccountCreateAttestation.ts (1)
validateXChainAddAccountCreateAttestation(89-123)
packages/xrpl/test/models/NFTokenCancelOffer.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenCancelOffer.ts (1)
validateNFTokenCancelOffer(41-51)
packages/xrpl/test/models/AMMBid.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMBid.ts (1)
validateAMMBid(61-106)
packages/xrpl/test/models/CredentialCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/CredentialCreate.ts (1)
validateCredentialCreate(47-59)
packages/xrpl/test/models/AMMWithdraw.test.ts (3)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMWithdraw.ts (1)
validateAMMWithdraw(83-125)packages/xrpl/src/models/transactions/index.ts (1)
AMMWithdrawFlags(32-32)
packages/xrpl/test/models/offerCancel.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/clawback.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/clawback.ts (1)
validateClawback(43-70)
packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (2)
packages/xrpl/src/models/transactions/index.ts (2)
NFTokenCreateOfferFlagsInterface(72-72)NFTokenCreateOfferFlags(71-71)packages/xrpl/src/models/utils/index.ts (1)
isFlagEnabled(25-28)
packages/xrpl/test/models/ticketCreate.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/NFTokenCreateOffer.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (1)
validateNFTokenCreateOffer(123-161)
packages/xrpl/test/models/AMMCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMCreate.ts (1)
validateAMMCreate(48-80)
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts (1)
validateMPTokenIssuanceSet(66-86)
packages/xrpl/test/models/XChainCommit.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCommit.ts (1)
validateXChainCommit(62-76)
packages/xrpl/test/models/XChainCreateClaimID.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCreateClaimID.ts (1)
validateXChainCreateClaimID(46-54)
packages/xrpl/test/models/XChainModifyBridge.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainModifyBridge.ts (1)
validateXChainModifyBridge(69-77)
packages/xrpl/test/models/AMMDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMDelete.ts (1)
validateAMMDelete(37-55)
packages/xrpl/test/models/paymentChannelFund.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/AMMDeposit.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMDeposit.ts (1)
validateAMMDeposit(85-131)
packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts (1)
validateMPTokenIssuanceCreate(124-180)
packages/xrpl/test/models/NFTokenMint.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenMint.ts (1)
validateNFTokenMint(146-180)
packages/xrpl/test/models/payment.test.ts (3)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/payment.ts (1)
validatePayment(173-212)packages/xrpl/src/models/transactions/index.ts (1)
PaymentFlags(88-88)
packages/xrpl/test/models/oracleSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/oracleSet.ts (1)
validateOracleSet(75-198)
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainAddClaimAttestation.ts (1)
validateXChainAddClaimAttestation(85-117)
🪛 Biome (1.9.4)
packages/xrpl/test/models/oracleDelete.test.ts
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 75-75: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 87-87: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainSet.test.ts
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/DIDSet.test.ts
[error] 52-52: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 54-54: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateBridge.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelClaim.test.ts
[error] 46-46: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainDelete.test.ts
[error] 31-31: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainClaim.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 86-86: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/trustSet.test.ts
[error] 40-40: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMVote.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 49-49: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 61-61: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelCreate.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 38-38: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 51-51: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 63-63: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts
[error] 59-59: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 71-71: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 107-107: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 125-125: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 143-143: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 161-161: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 179-179: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 197-197: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 215-215: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 233-233: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMBid.test.ts
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 80-80: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMWithdraw.test.ts
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 101-101: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/offerCancel.test.ts
[error] 47-47: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/ticketCreate.test.ts
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMCreate.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 60-60: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMClawback.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 55-55: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 91-91: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCommit.test.ts
[error] 43-43: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 55-55: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateClaimID.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainModifyBridge.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDelete.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 49-49: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelFund.test.ts
[error] 33-33: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDeposit.test.ts
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 90-90: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/payment.test.ts
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 83-83: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCreate.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 42-42: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 84-84: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 85-85: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCancel.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 42-42: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleSet.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 114-114: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 128-128: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 135-135: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 142-142: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 149-149: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 65-65: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 83-83: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 107-107: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 125-125: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 137-137: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 149-149: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 167-167: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 179-179: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
🔇 Additional comments (211)
packages/xrpl/HISTORY.md (1)
14-14: Good addition of documentation for the fix.This entry clearly explains that a bug was fixed which caused some transactions to crash during validation.
packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts (1)
72-72: Improved robustness by adding default value for Flags.The addition of the nullish coalescing operator (
??) ensures thatflagswill default to0whentx.Flagsis undefined or null, preventing potential runtime errors during flag checks.packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts (1)
160-162: Fixed potential crash by adding default value for Flags.Using the nullish coalescing operator to default
tx.Flagsto0when undefined or null prevents potential runtime errors during flag validation. This aligns with the related fix in MPTokenIssuanceSet.ts.packages/xrpl/test/models/baseTransaction.test.ts (2)
6-9: Good refactoring with helper functions.Creating
assertValidandassertInvalidhelper functions improves code readability and reduces duplication. This follows good DRY (Don't Repeat Yourself) principles.
64-64: Test code refactored for better maintainability.All assertions have been updated to use the new helper functions, making the tests more consistent and easier to maintain while preserving the original test logic.
Also applies to: 73-73, 83-83, 93-93, 103-103, 113-116, 126-126, 136-136, 146-149, 159-159, 169-169, 183-183, 200-200, 209-209
packages/xrpl/test/models/NFTokenCancelOffer.test.ts (4)
1-7: Good refactoring approach with centralized test utilitiesThe introduction of helper functions
assertValidandassertInvalidthat utilize the shared test utilities creates a more consistent and maintainable test structure. This approach reduces duplication and standardizes validation assertions.
28-28: LGTM - Clean test refactoringThe refactored assertion using the helper function makes the test more concise while preserving the functionality.
40-40: LGTM - Consistent error validationThe refactored error assertion using
assertInvalidenforces consistent validation between the specific validator and the generic validator.
53-53: LGTM - Consistent error validationThe refactored error assertion for empty NFTokenOffers now follows the same pattern as other validations.
packages/xrpl/test/models/escrowFinish.test.ts (4)
1-6: Good separation of concerns with helper functionsThe introduction of
assertValidandassertInvalidhelper functions properly encapsulates the validation logic, making tests more readable and consistent.
14-14: LGTM - Explicit type annotationExplicitly typing
escrowasanymakes the type expectations clearer.
31-31: LGTM - Consistent validation assertionsThe positive validation tests now use the standardized
assertValidhelper, ensuring both specific and generic validation are checked consistently.Also applies to: 39-39, 45-45
51-51: LGTM - Standardized error validationThe negative validation tests now use the standardized
assertInvalidhelper, which ensures both specific and generic validation throw the same errors.Also applies to: 57-57, 63-63, 69-69, 78-78, 97-97, 105-105, 116-116, 128-128
packages/xrpl/test/models/checkCash.test.ts (3)
1-6: Good pattern for test utilitiesThe helper functions
assertValidandassertInvalideffectively wrap the shared utilities, providing a clean interface specific to CheckCash validation.
24-24: LGTM - Improved valid transaction testingUsing the helper ensures both specific and generic validation are checked consistently.
35-35: LGTM - Improved error validation testingThe refactored error assertions using
assertInvalidmake the tests more concise while ensuring both validators are checked with the same error message.Also applies to: 47-47, 60-63, 75-75
packages/xrpl/test/models/oracleDelete.test.ts (4)
1-6: Good extraction of test utilitiesThe helper functions create a clean abstraction for the validation testing, making the test code more focused and maintainable.
14-14: LGTM - Explicit type annotationExplicitly typing
txasanyimproves code clarity.
25-25: LGTM - Standardized validation testingThe positive validation test now uses the standardized
assertValidhelper.
37-37: LGTM - Consistent error validationUsing the
assertInvalidhelper for invalid OracleDocumentID ensures both validators are checked with the same error message.packages/xrpl/test/models/NFTokenModify.test.ts (3)
1-9: Improved test structure with reusable validation helpersThe implementation of helper functions
assertValidandassertInvalidthat wrap the transaction-specific validation creates a cleaner testing pattern. This approach reduces code duplication and simplifies test assertions throughout the file.
27-27: Standardized hex conversionGood change replacing
convertStringToHexwithstringToHexfrom the isomorphic utilities package, which helps maintain consistency across the codebase.
30-30: Simplified validation assertionsThe use of specialized helper functions improves test readability and makes error messages more consistent across the test suite.
Also applies to: 41-41, 54-54, 67-67
packages/xrpl/test/models/CredentialAccept.test.ts (3)
4-9: Improved test structure with reusable validation helpersGood implementation of helper functions to standardize validation assertions, consistent with the pattern applied across other transaction test files.
17-17: Enhanced type clarityExplicitly typing
credentialAcceptasanyimproves code readability and makes it clear that the variable has a flexible structure for testing different validation scenarios.
31-31: Consistent validation patternThe consistent use of helper functions for all validation assertions improves maintainability and makes the test logic more apparent.
Also applies to: 37-37, 43-43, 49-49, 55-55, 61-61, 68-68, 75-75, 82-82
packages/xrpl/test/models/escrowCancel.test.ts (2)
2-6: Improved test structure with reusable validation helpersThe helper functions create a consistent pattern for testing transaction validation, making the tests more readable and maintainable.
14-14: Enhanced type clarityExplicitly typing
cancelasanyimproves code readability and clarifies its usage in the test cases.packages/xrpl/test/models/checkCreate.test.ts (2)
2-6: Improved test structure with reusable validation helpersThe implementation of validation helper functions follows the consistent pattern applied across the transaction test files, improving code organization and readability.
27-27: Streamlined validation assertionsThe use of the specialized helper functions makes the test assertions more concise and consistent, improving the overall quality of the test suite.
Also applies to: 43-43, 59-59, 75-78, 94-94, 109-109
packages/xrpl/test/models/ticketCreate.test.ts (5)
2-6: LGTM! Well-structured test helper extraction.The addition of utility functions
assertTxIsValidandassertTxValidationErrorfrom testUtils and the creation of local helper wrappersassertValidandassertInvalidmakes the test code cleaner and more maintainable.
14-14: Appropriate type annotation for test object.Changing the type to
anyis appropriate for test variables since we're testing validation scenarios with potentially invalid data structures.
25-25: Clean assertion replacement.The use of the helper function
assertValidsimplifies the test code while maintaining the same validation checks.
30-30: Simplified validation error assertion.Using
assertInvalidwith the specific error message improves readability while ensuring both specific and generic validators throw the expected error.
35-35: Consistent error validation pattern.The rest of the test cases follow the same pattern of using
assertInvalidwith the appropriate error message. This consistent approach improves maintainability and readability.Also applies to: 40-43, 48-51, 56-59
packages/xrpl/test/models/CredentialDelete.test.ts (3)
4-9: LGTM! Consistent test utilities implementation.The implementation of test utilities follows the same pattern as other test files, enhancing consistency across the codebase.
17-17: Appropriate type annotation.The explicit
anytype annotation forcredentialDeleteis appropriate for testing scenarios with potentially invalid data.
32-32: Consistent assertion refactoring across test cases.All test assertions have been systematically refactored to use the helper functions, which improves code consistency and reduces duplication.
Also applies to: 38-38, 44-44, 50-50, 56-56, 64-64, 70-70, 77-77, 84-84, 91-91
packages/xrpl/test/models/permissionedDomainSet.test.ts (4)
3-10: LGTM! Well-structured imports and helper functions.The refactoring includes appropriate imports and helper function definitions that follow the consistent pattern established across test files.
18-18: Clear variable naming.Renaming to
txis more clear and consistent with the variable's purpose as a transaction object under test.
37-37: Simplified validation assertion.Using
assertValidsimplifies the test code while maintaining the same validation checks.
44-44: Consistent error validation pattern.All validation error test cases have been systematically refactored to use the
assertInvalidhelper, which improves code consistency and reduces duplication.Also applies to: 51-51, 57-60, 65-68, 73-76, 81-84, 89-89
packages/xrpl/test/models/accountSet.test.ts (4)
2-6: LGTM! Consistent utility implementation.The implementation of test utilities follows the same pattern as other test files, enhancing consistency across the codebase.
14-14: Improved variable naming.Renaming from
accounttotxmakes the variable name clearer and more consistent with its purpose as a transaction object under test.
30-30: Simplified validation assertion.Using
assertValidsimplifies the test code while maintaining the same validation checks.
34-35: Consistent error validation pattern.All validation error test cases have been systematically refactored to use the
assertInvalidhelper, which improves code consistency and readability.Also applies to: 39-40, 44-45, 49-50, 54-55, 59-60, 64-65, 69-70, 74-75
packages/xrpl/test/models/oracleSet.test.ts (3)
4-8: Well-structured utility function implementation.The addition of these helper functions greatly improves test readability and maintenance. By wrapping the generic assertion utilities with transaction-specific validation functions, you've created a clean interface for validation tests.
16-16: Good explicit typing for test variables.Explicitly typing
txasanyimproves code clarity and follows the TypeScript pattern used in other test files.
41-42: Consistent test assertion pattern improves readability.The replaced validation assertions with
assertValidandassertInvalidhelper functions make tests more consistent and easier to maintain. This standardized approach eliminates the need for repetitive try-catch blocks or direct assertion handling.Also applies to: 47-48, 53-54, 59-60, 65-66, 71-72, 77-78, 83-84, 89-90, 96-97, 110-111, 117-118, 124-125, 131-132, 138-139, 145-146, 152-153, 160-161, 166-167, 173-174, 179-180, 185-186, 191-192
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (2)
1-7: Clean implementation of test utilities.The refactoring follows the same pattern applied to other model test files, creating a consistent approach across the codebase. The helper functions
assertValidandassertInvalidimprove test clarity and maintainability.
24-24: Improved assertion pattern for validation tests.The new assertion pattern is more concise and consistent with other test files in the codebase. This standardized approach eliminates the need for repetitive error handling code.
Also applies to: 33-36
packages/xrpl/test/models/NFTokenAcceptOffer.test.ts (2)
1-7: Consistent utility function implementation.The refactoring follows the same pattern applied to other model test files, creating a consistent approach across the codebase. The helper functions provide a clean interface for validation tests.
30-30: Standardized assertion pattern improves test clarity.The replacement of direct validation calls with helper functions makes the tests more concise and easier to understand. This consistent pattern across all test cases enhances maintainability.
Also applies to: 43-43, 55-58, 72-75, 89-92, 106-106, 121-121, 136-139, 154-157, 172-172
packages/xrpl/test/models/clawback.test.ts (2)
1-6: Well-structured utility function implementation.The refactoring follows the same pattern applied throughout the test suite, improving consistency and readability. The helper functions encapsulate validation logic, making test assertions more concise.
25-25: Consistent test assertion pattern enhances readability.The standardized approach to validation assertions eliminates repetitive error handling code and creates a consistent pattern across all test cases. This refactoring improves maintainability without changing the test coverage or validation criteria.
Also applies to: 34-34, 44-44, 52-52, 66-66, 80-80, 94-94, 107-107, 122-122
packages/xrpl/test/models/trustSet.test.ts (4)
2-6: Good refactoring: Helper functions improve test readabilityThe introduction of
assertTxIsValidandassertTxValidationErrorutility functions, along with the local wrapper functionsassertValidandassertInvalid, greatly improves the readability and maintainability of these tests. This approach centralizes the validation logic and makes test assertions more concise.
14-14: Type annotation improves code clarityAdding the explicit
anytype to thetrustSetvariable makes the code more maintainable by clearly indicating the expected type, which is appropriate for test fixtures that need flexibility.
36-36: Simplified test assertionReplacing the direct validation calls with the
assertValidhelper function makes the test more concise and focuses on what's being tested rather than how it's being tested.
41-41: Consistent error validation patternUsing the
assertInvalidhelper provides a consistent way to test validation failures across all tests, which improves maintainability.packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (13)
1-5: Good import refactoringReplacing
convertStringToHexwithstringToHexfrom the isomorphic utilities package and updating the imports to include the validation utilities is a good practice that aligns with modern dependency management.
7-10: Helper functions improve test clarityThe introduction of
assertValidandassertInvalidhelper functions creates a more readable and maintainable testing pattern by abstracting away the validation details.
27-27: Updated to use stringToHex utilityCorrectly updated to use the
stringToHexutility function from the isomorphic package, which improves cross-platform compatibility.
30-30: Improved test assertionThe test assertion has been simplified by using the
assertValidhelper, focusing the test on what's being validated rather than the validation mechanics.
41-44: Consistent error message testingThe refactored code maintains the same validation error message checks but in a more standardized and readable format using the helper functions.
55-58: Standardized validation testingThe refactored code ensures consistent validation testing across different test cases, making the codebase more maintainable.
68-68: Simplified error case testingThe single-line assertion makes the test case more concise while still validating the same error condition.
76-76: Consistent error validation patternThe consistent use of
assertInvalidacross all error test cases improves code readability and maintainability.
84-84: Standardized error validationUsing the same helper function for different error scenarios ensures consistent testing patterns throughout the test suite.
94-97: Improved error message testingThe helper function correctly validates that both the specific validator and the generic validate function throw the expected error message.
105-108: Consistent validation testingMaintaining the same pattern across different test cases improves code readability and reduces cognitive load when reviewing the tests.
116-119: Consistent error validationUsing a standardized approach for validating complex error conditions involving flag checks improves test clarity.
128-131: Standardized complex validation testingThe helper function handles complex validation scenarios involving flag combinations consistently across the test suite.
packages/xrpl/test/models/escrowCreate.test.ts (13)
2-6: Good refactoring: Helper functions improve test consistencyAdding
assertTxIsValidandassertTxValidationErrorutilities with local wrappersassertValidandassertInvalidprovides a more consistent testing approach across the codebase.
14-14: Type annotation improves code clarityAdding the explicit
anytype to theescrowvariable makes the code more maintainable by clearly indicating the expected type.
32-32: Simplified test assertionThe replaced assertion improves readability while maintaining the same validation logic.
38-38: Consistent error validation patternUsing the
assertInvalidhelper provides a consistent pattern for testing validation failures.
44-44: Standardized error testingThe consistent use of
assertInvalidacross different test cases reduces code duplication and improves maintainability.
50-50: Improved error validationThe helper function correctly validates that both the specific validator and the generic validate function throw the expected error message.
56-56: Consistent validation approachMaintaining the same assertion pattern across different test cases enhances readability.
62-62: Standardized validation testingUsing a consistent approach for validating different field types improves code readability.
68-68: Consistent error testing patternThe helper function effectively validates error conditions for the FinishAfter field.
74-74: Standardized validation testingThe consistent use of helper functions across different test cases simplifies the test code.
80-80: Improved error validationThe helper function effectively validates the error condition for invalid DestinationTag fields.
87-90: Cleaner validation of complex conditionsUsing the helper function to test more complex validation rules involving multiple fields creates more maintainable test code.
97-100: Consistent complex validation testingThe helper functions handle complex validation scenarios involving multiple fields consistently across the test suite.
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (11)
2-7: Good refactoring: Helper functions improve test consistencyThe introduction of
assertTxIsValidandassertTxValidationErrorutilities with local wrappersassertValidandassertInvalidprovides a more consistent testing approach across the codebase. This standardizes validation testing and improves readability.
15-15: Type annotation improves code clarityAdding the explicit
anytype to thetxvariable makes the code more maintainable by clearly indicating the expected type for the test fixture.
41-41: Simplified test assertionUsing the
assertValidhelper function makes the test more concise and readable.
47-47: Standardized error validationThe consistent use of
assertInvalidfor testing validation failures improves test code readability.
53-53: Consistent validation approachMaintaining the same assertion pattern across different test cases enhances readability and maintainability.
59-62: Standardized multi-line validationThe helper function effectively handles multi-line validation error messages in a consistent format.
68-71: Improved error validationUsing the helper function consistently for different validation scenarios reduces code duplication.
77-77: Standardized validation testingThe consistent approach for testing missing required fields improves code readability.
83-83: Consistent error testing patternUsing the helper function for testing invalid field types maintains consistency across test cases.
89-89: Standardized validation testingThe helper function effectively tests missing required fields in a consistent manner.
95-95: Consistent validation approachThe helper function maintains consistent validation testing for invalid field types.
packages/xrpl/test/models/paymentChannelCreate.test.ts (3)
2-7: Good refactoring to improve test consistencyThe introduction of helper functions
assertValidandassertInvalidthat wrap the utility functions fromtestUtilssimplifies the test code and makes it more consistent across the test suite. This pattern makes the test assertions more readable and maintainable.
15-15: LGTM: Explicit type annotation addedExplicitly typing the
channelvariable asanyclarifies the intent and prevents potential type errors.
33-33: Consistent assertion pattern applied throughout testsThe consistent use of the new helper functions
assertValidandassertInvalidacross all test cases improves code clarity and maintainability. This standardized approach makes it easier to understand the expected behavior in each test case.Also applies to: 41-41, 47-47, 53-53, 59-59, 65-65, 71-71, 77-77, 83-83, 89-89, 95-95, 101-101
packages/xrpl/test/models/AMMVote.test.ts (3)
2-6: Good refactoring to standardize test assertionsThe introduction of helper functions
assertValidandassertInvalidthat wrap the utility functions fromtestUtilsimproves code clarity and consistency across the test suite. This approach centralizes validation logic and makes tests more maintainable.
14-14: LGTM: Explicit type annotation addedExplicitly typing the
votevariable asanyclarifies the intent and prevents potential type errors in the test code.
33-33: Consistent assertion pattern applied throughout testsThe consistent use of the new helper functions across all test cases improves code clarity and maintainability. This standardized approach makes it easier to understand the expected behavior in each test case.
Also applies to: 39-39, 45-45, 51-51, 57-57, 63-63, 69-69, 75-75, 81-81
packages/xrpl/test/models/AMMCreate.test.ts (3)
2-6: Good refactoring to standardize test assertionsThe introduction of helper functions
assertValidandassertInvalidthat wrap the utility functions fromtestUtilsimproves code clarity and consistency across the test suite. This approach centralizes validation logic and makes tests more maintainable.
14-14: LGTM: Type annotations improvedThe explicit typing of
ammCreateasanyand removal of the redundantas anytype casting at the end of the object declaration improves type clarity in the code.Also applies to: 28-28
32-32: Consistent assertion pattern applied throughout testsThe consistent use of the new helper functions across all test cases improves code clarity and maintainability. This standardized approach makes it easier to understand the expected behavior in each test case.
Also applies to: 38-38, 44-44, 50-50, 56-56, 62-62, 68-68, 74-74, 80-80
packages/xrpl/test/models/NFTokenBurn.test.ts (2)
1-6: Good refactoring to standardize test assertionsThe introduction of helper functions
assertValidandassertInvalidthat wrap the utility functions fromtestUtilsimproves code clarity and makes the tests more consistent with the rest of the test suite. This approach centralizes validation logic and makes tests more maintainable.
27-27: Consistent assertion pattern applied throughout testsThe refactoring to use the new helper functions
assertValidandassertInvalidmakes the test assertions more consistent with the test patterns used in other files, improving overall code readability and maintainability.Also applies to: 39-39
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts (3)
2-7: Great abstraction with helper functions!The introduction of
assertValidandassertInvalidhelper functions makes the test code more concise and consistent. This approach centralizes validation logic and reduces code duplication across test cases.
15-15: Good practice adding explicit typingExplicitly typing
txasanyimproves code clarity and makes the TypeScript compiler happy.
49-49: Clean implementation of the refactored assertionsReplacing direct validation calls with the helper functions makes the tests more readable and maintainable. The refactoring maintains the same validation logic while streamlining the code.
Also applies to: 55-55, 61-61, 67-69
packages/xrpl/test/models/XChainCreateBridge.test.ts (3)
2-7: Excellent use of utility functions for consistent test patternsThe introduction of
assertValidandassertInvalidhelper functions follows the same pattern as other test files, providing a consistent approach to transaction validation testing throughout the codebase.
15-15: Good practice with explicit typingExplicitly typing
txasanyimproves code clarity and helps with TypeScript's type checking.
40-40: Clean and consistent implementationThe refactored assertions maintain the same validation checks but with cleaner, more maintainable code. This approach makes error messages more visible and centralizes the validation logic.
Also applies to: 46-46, 52-52, 58-58, 64-64, 70-73
packages/xrpl/test/models/offerCancel.test.ts (4)
2-6: Good pattern with helper functionsThe addition of
assertValidandassertInvalidhelper functions follows the same consistent pattern seen in other test files, making the test code more concise and easier to maintain.
14-14: Good practice with explicit typingExplicitly typing the
offervariable asanyimproves code clarity and TypeScript type awareness.
33-33: Clean implementation of refactored assertionsThe updated assertion calls make the tests more readable and consistent with other transaction model tests.
Also applies to: 38-38, 43-44, 48-48
42-42: Good improvement to test clarityChanging the invalid OfferSequence value from what was likely a numeric string to a clearly non-numeric string
'abcd'makes the test more explicit about what's being tested - that OfferSequence must be a number.packages/xrpl/test/models/signerListSet.test.ts (3)
2-7: Well-implemented helper functionsThe introduction of
assertValidandassertInvalidhelper functions follows the same consistent pattern as other test files, improving code readability and maintaining consistent validation checks.
15-15: Good practice with explicit typingExplicitly typing
signerListSetTxasanyimproves code clarity and TypeScript type checking.
48-48: Clean and consistent assertion implementationThe refactored assertions maintain the same validation logic while making the code more concise and easier to read. The consistent pattern across tests enhances maintainability.
Also applies to: 54-54, 60-63, 69-69, 121-121, 151-151, 173-173
packages/xrpl/test/models/AMMDelete.test.ts (3)
2-6: Clean refactoring using utility functions!The introduction of
assertTxIsValidandassertTxValidationErrorutilities, wrapped in local helper functionsassertValidandassertInvalid, is an excellent refactoring choice. This approach simplifies the test code and provides a consistent validation pattern across the test suite.
14-14: Good type annotation.Explicitly typing
ammDeleteasanyimproves clarity about the variable's intended usage.
33-33: Tests are simplified and consistent.The test assertions are now more readable and consistent, using the new helper functions while maintaining the same validation coverage.
Also applies to: 39-39, 45-45, 51-51, 57-57
packages/xrpl/test/models/AMMBid.test.ts (3)
2-6: Well-structured refactoring using utility functions!The introduction of imported assertion utilities and local helper functions creates a clean abstraction and improves test readability. This consistent pattern makes the validation logic more maintainable.
14-14: Good type annotation.Explicitly typing
bidasanyimproves code clarity.
64-64: Tests are simplified and consistent.The test assertions have been successfully refactored to use the new helper functions, making them more concise while maintaining the same validation coverage.
Also applies to: 70-70, 76-76, 82-82, 88-88, 94-94, 100-100, 111-111, 117-117, 133-133, 141-141, 151-151, 162-162
packages/xrpl/test/models/AMMClawback.test.ts (3)
5-9: Excellent refactoring using utility functions!The introduction of assertion utilities and helper functions simplifies the test code and provides a consistent pattern for validation. This approach improves maintainability and readability.
17-17: Good type annotation.Explicitly typing
ammClawbackasanyimproves code clarity.
41-41: Tests are simplified and consistent.The test assertions are now more readable and consistent using the new helper functions while maintaining the same validation coverage.
Also applies to: 46-46, 51-51, 57-57, 63-63, 69-69, 75-75, 81-81, 87-87, 93-93, 99-99, 105-105, 112-112, 118-118
packages/xrpl/test/models/DIDSet.test.ts (3)
2-6: Great refactoring with utility functions!The introduction of assertion utilities and helper functions provides a clean abstraction that simplifies test code and creates a consistent validation pattern.
14-14: Good type annotation.Explicitly typing
txasanyimproves code clarity.
30-30: Tests are simplified and consistent.The test assertions have been successfully refactored to use the new helper functions, making them more concise while maintaining the same validation coverage.
Also applies to: 36-36, 42-42, 48-48, 56-59
packages/xrpl/test/models/XChainClaim.test.ts (3)
2-6: Helper functions improve code maintainability.The introduction of utility imports and helper functions is a good refactoring. This centralizes validation logic and makes test assertions more consistent and concise.
14-14: Explicit type annotation clarifies variable usage.Explicitly typing
txasanymakes it clear that the transaction object doesn't conform to a specific interface, which is helpful for understanding the test context.
40-40: Test assertions refactored to use helper functions.The replacement of direct validation calls with helper functions makes the test code more concise and easier to maintain. This approach ensures consistent validation behavior across tests.
Also applies to: 46-46, 52-52, 58-58, 64-64, 70-70, 76-76, 82-82, 88-88, 94-94
packages/xrpl/test/models/checkCancel.test.ts (2)
2-6: Improved test structure with helper functions.The addition of utility imports and helper functions simplifies the test code and ensures consistent validation behavior across test cases.
22-22: Simplified test assertions.Using the helper functions makes the test assertions more concise while maintaining the same validation coverage. This is a good refactoring that aligns with the pattern used across other test files.
Also applies to: 32-32
packages/xrpl/test/models/AMMDeposit.test.ts (3)
3-9: Streamlined test setup with helper functions.The refactoring improves code maintainability by:
- Using specific import for
AMMDepositFlagsinstead of a broader import- Adding utility functions for consistent validation assertions
- Creating helper functions that encapsulate the validation logic
This approach reduces duplication and ensures consistent testing patterns.
22-22: Explicit type annotation adds clarity.Explicitly typing
depositasanyclarifies that the transaction object is loosely typed in the test context, which is appropriate for testing validation behavior.
43-43: Simplified test assertions with helper functions.The replacement of direct assertions with helper functions makes the test code more concise and easier to maintain, while preserving the same validation logic.
Also applies to: 49-49, 60-60, 67-67, 74-74, 80-80, 86-86, 92-92, 98-98, 103-103, 113-113, 119-119, 126-126, 132-132, 139-139, 146-146
packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (2)
149-155: Improved robustness for flags handling.This change properly handles the
Flagsfield by:
- Setting a default value of
0whenFlagsis undefined or null- Supporting both numeric and object representations for flags
- Using nullish coalescing to provide a default value for
tfSellNFTokenThis prevents potential runtime errors when checking flags and makes the validation more robust.
156-156: Simplified conditional using extracted flag value.Using the previously computed
isTfSellNFTokenvalue for the conditional makes the code more readable and directly connects to the logic in lines 151-154.packages/xrpl/test/models/MPTokenAuthorize.test.ts (7)
2-3: Clean import restructuring to support the refactoring pattern.Nice job updating the imports to include only what's needed for the new helper pattern, removing unnecessary imports.
5-8: Good introduction of helper functions for cleaner test assertions.These helper functions nicely encapsulate the validation logic, making the test code more readable and maintainable. The pattern of creating local wrapper functions makes the test assertions much more concise.
25-25: Clean replacement of direct assertion with helper function.The new assertion style is more concise and consistent with the broader refactoring pattern being applied across test files.
34-34: Consistent application of the assertion helper pattern.This change follows the same pattern as the previous test case, maintaining consistency throughout the file.
43-43: Consistent validation approach for flag testing.Good job applying the same validation pattern when testing with flags.
53-53: Consistent validation approach for complex test cases.The helper pattern is consistently applied even for more complex test cases, improving readability.
62-62: Effective use of the error assertion helper for validation testing.The
assertInvalidhelper appropriately checks for the expected validation error, maintaining the same validation logic while simplifying the test code.packages/xrpl/test/models/paymentChannelFund.test.ts (3)
2-7: Well-structured helper functions for consistent test assertions.Good job introducing the helper functions that standardize validation patterns across test files. This makes the tests more maintainable and easier to understand.
15-15: Improved type clarity by explicitly typing the channel variable.Explicitly typing
channelasanymakes the code more readable and consistent with TypeScript best practices.
29-29: Consistent application of assertion helpers throughout all test cases.All test assertions have been consistently updated to use the new helper functions, making the test suite more uniform and easier to maintain.
Also applies to: 35-35, 41-41, 47-47, 53-53, 59-59, 65-65
packages/xrpl/test/models/permissionedDomainDelete.test.ts (3)
2-7: Well-structured helper functions that simplify the test code.The helper functions effectively encapsulate the validation logic, making the test assertions more concise and readable.
15-15: Improved type clarity with explicit typing.Explicitly typing
txasanyimproves code readability and TypeScript compliance.
27-27: Consistent application of the assertion pattern across all test cases.Good job applying the new assertion pattern consistently throughout all test cases, maintaining a uniform testing approach.
Also applies to: 33-33, 39-39
packages/xrpl/test/models/offerCreate.test.ts (4)
2-6: Well-designed helper functions that improve test readability.The helper functions effectively encapsulate the validation logic, making the test assertions more concise and consistent across the codebase.
36-37: Clean replacement of validation assertions with helper functions.The new assertion style is more concise and readable, reducing boilerplate code while maintaining the same test logic.
Also applies to: 59-60, 86-87
39-39: Clear, descriptive test case titles.The test case titles accurately describe what's being tested, making the test suite easier to understand and maintain.
Also applies to: 62-62
110-110: Consistent error validation pattern across all test cases.Good job applying the same error validation pattern consistently across all invalid test cases, which improves maintainability.
Also applies to: 134-134, 154-154, 178-178
packages/xrpl/test/models/setRegularKey.test.ts (3)
2-7: Good refactoring to use assertion utilities!The introduction of the
assertTxIsValidandassertTxValidationErrorutilities with local wrapper functionsassertValidandassertInvalidimproves code consistency and readability. This pattern encapsulates both the specific and generic validation checks in a cleaner way.
15-15: Improved variable naming for clarityRenaming the variable from
accounttotxmakes the purpose clearer and matches the naming convention used across other test files.
28-28: Standardized validation approachThe replacement of direct validation calls with the helper functions creates a consistent pattern for validation, making the tests more maintainable and easier to understand.
Also applies to: 32-34, 37-39
packages/xrpl/test/models/NFTokenCreateOffer.test.ts (3)
1-8: Well-structured test utilities setupGood implementation of the helper functions that wrap the transaction validation utilities. This pattern encapsulates the validation logic and makes the tests more concise and readable.
32-32: Improved validation assertions for successful casesThe refactoring to use
assertValid()simplifies the positive test cases and ensures consistent validation via both the specific validator and the generic validate function.Also applies to: 50-50, 66-66
81-84: Improved error validation consistencyThe refactoring to use
assertInvalid()with expected error messages creates a more consistent pattern for error validation across all test cases. This approach ensures that both the specific validator and the generic validate function throw the same error with the expected message.Also applies to: 100-103, 118-118, 134-134, 149-149, 165-168, 182-185, 200-203
packages/xrpl/test/models/XChainCommit.test.ts (3)
2-6: Clean implementation of validation utilitiesThe helper functions are concisely defined and maintain the same validation behavior while improving code readability.
14-14: Explicit typing improves code clarityAdding explicit type annotation
tx: anyimproves code clarity and maintainability.
39-39: Consistent validation pattern across test casesThe updated validation assertions create a uniform pattern that's easier to follow and maintain.
Also applies to: 45-45, 51-51, 57-57, 63-63, 69-69, 75-75, 81-81
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (3)
1-8: Good implementation of test utilitiesThe import of specific flags and validation functions along with the implementation of helper functions for validation assertions creates a clean and maintainable test structure.
26-26: Simplified validation for successful test casesThe refactoring to use
assertValid()improves code readability while maintaining the same validation logic.Also applies to: 36-36, 46-46
55-58: Consistent error validationThe refactoring to use
assertInvalid()creates a uniform pattern for validating error cases, improving consistency across the test suite.Also applies to: 72-72, 76-76
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts (4)
2-11: Excellent refactoring to improve test consistencyThe introduction of helper functions
assertValidandassertInvalidthat wrap the utility functions fromtestUtilsgreatly improves code readability and maintainability. This pattern centralizes validation logic and simplifies all test cases by removing redundant code.
19-19: Good explicit typingExplicitly typing
txasanyclarifies the intention and matches the parameter types expected by the utility functions.
55-56: Improved test assertionReplacing the direct validation with the
assertValidhelper function makes the test more concise and consistent with the rest of the test suite.
61-62: Simplified validation error assertionUsing the
assertInvalidhelper function reduces boilerplate and makes the test intent clearer.packages/xrpl/test/models/accountDelete.test.ts (5)
2-7: Consistent refactoring approachThe helper functions match the pattern used across other test files, providing a unified approach to transaction validation testing.
15-15: Proper variable typingExplicitly typing
validAccountDeleteasanyensures type consistency with the helper functions.
29-30: Enhanced test fixture definitionThe test fixture is now more cleanly defined with proper typing.
32-33: Simplified valid transaction testingThe
assertValidhelper function makes the successful validation test more readable.
38-39: Consistent error validation patternUsing the
assertInvalidhelper maintains consistency with the project's new testing pattern.packages/xrpl/test/models/XChainCreateClaimID.test.ts (4)
2-7: Well-implemented helper functionsThese helper functions effectively wrap the imported utility functions, providing a clean interface for test assertions.
15-15: Appropriate typingExplicitly typing
txasanymatches the approach taken across the codebase.
40-41: Clear and concise validation testingThe
assertValidhelper simplifies the test and improves readability.
46-47: Consistent error validationThe
assertInvalidhelper function provides a clean way to test for specific validation errors.packages/xrpl/test/models/XChainModifyBridge.test.ts (4)
2-7: Consistent helper function implementationThe helper functions here match the pattern used across other test files, maintaining consistency throughout the test suite.
15-15: Proper type declarationExplicitly typing
txasanymatches the approach used in other test files.
40-41: Simplified validation testingUsing
assertValidmakes the test more readable and consistent with other test files.
64-67: Improved multi-line assertionThe multi-line format for longer error messages improves readability while maintaining the consistent testing pattern.
packages/xrpl/test/models/depositPreauth.test.ts (3)
3-10: Clean refactoring with improved test utilitiesThe introduction of
assertTxIsValidandassertTxValidationErrorutilities with local wrapper functionsassertValidandassertInvalidis a good improvement that removes duplicate validation code across test files.
18-18: Good practice explicitly typing test variablesExplicitly typing the test variable as
anyimproves code clarity, especially when dealing with test fixtures.
36-36: Clean test assertionThe refactored code uses the new utility function which improves readability while maintaining the same validation logic.
packages/xrpl/test/models/NFTokenMint.test.ts (2)
1-9: Good refactoring to use standardized utilitiesThe file now uses the centralized validation utilities and adds local wrapper functions to improve test readability. Using the standardized
stringToHexfrom the isomorphic utilities package is also a good improvement.
29-29: Consistent hex encoding for URIsUsing the standard
stringToHexfunction ensures consistent encoding of URIs across the codebase.packages/xrpl/test/models/AMMWithdraw.test.ts (1)
3-9: Good refactoring with standardized test utilitiesThe refactored code now uses the centralized test utilities with local wrapper functions that improve test readability and maintainability.
packages/xrpl/test/models/paymentChannelClaim.test.ts (1)
1-7: Good refactoring with standardized test utilitiesThe refactored code follows the consistent pattern of using centralized test utilities with local wrapper functions that improve readability and maintainability.
packages/xrpl/test/models/CredentialCreate.test.ts (5)
4-5: Good refactoring: Using utility functions for validation testsThe import of
assertTxIsValidandassertTxValidationErrorfromtestUtilsis a good addition that will simplify test code and standardize validation patterns across the test suite.
6-9: LGTM: Helper functions improve readabilityCreating
assertValidandassertInvalidhelper functions is a good approach that makes the test code more concise and readable while still maintaining the validation logic consistency.
17-17: LGTM: Explicit type annotationExplicitly typing
credentialCreateasanyimproves code clarity.
33-33: LGTM: Simplified validation assertionUsing the helper function
assertValidsimplifies the test code while maintaining the same validation checks.
39-39: LGTM: Consistent error validation patternUsing
assertInvalidconsistently across all error test cases improves code readability and maintainability.packages/xrpl/test/models/payment.test.ts (5)
3-5: Good refactoring: Improved importsImporting
PaymentFlagsdirectly and adding the test utility functions improves code organization and makes the intention of the code clearer.
7-9: LGTM: Helper functions improve readabilityCreating
assertValidandassertInvalidhelper functions is a good approach that makes the test assertions more consistent and easier to understand.
17-17: LGTM: Renaming for brevityShortening the variable name from
paymentTransactiontopaymentimproves readability throughout the test file.
98-99: LGTM: Testing X-address validationGood test case ensuring validation works correctly with X-addresses.
128-130: LGTM: Clear validation with flagsUsing the imported
PaymentFlagsenum improves code clarity compared to using numeric literals.packages/xrpl/test/models/DIDDelete.test.ts (3)
2-4: LGTM: Consistent test refactoringThe refactoring aligns with the pattern used in other test files, making the codebase more consistent.
12-12: LGTM: Explicit type annotationExplicitly typing
txasanyimproves code clarity.
25-25: LGTM: Simplified validation assertionUsing the helper function simplifies the test while maintaining the validation logic.
packages/xrpl/test/testUtils.ts (3)
8-13: LGTM: Updated importsAdding
validateandValidationErrorimports is necessary for the new utility functions.
60-69: LGTM: Excellent utility function for validation successWell-documented function that encapsulates the pattern of checking both transaction-specific validation and generic validation, improving code reuse across test files.
71-85: LGTM: Great complementary utility for validation failuresThis function pairs well with
assertTxIsValidto provide a complete validation testing toolkit. The JSDoc comments clearly explain the purpose and parameters.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (35)
packages/xrpl/test/models/escrowCancel.test.ts (1)
36-36: Minor suggestion regardingdeleteoperator.Consider using undefined assignment instead of the
deleteoperator for slightly better performance, e.g.,cancel.Owner = undefinedinstead ofdelete cancel.Owner.- delete cancel.Owner + cancel.Owner = undefined- delete cancel.OfferSequence + cancel.OfferSequence = undefinedAlso applies to: 42-42
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateBridge.test.ts (1)
44-44: Consider using undefined assignment instead of delete.The static analysis tool flagged the use of the
deleteoperator, which can impact performance.- delete tx.XChainBridge + tx.XChainBridge = undefined- delete tx.SignatureReward + tx.SignatureReward = undefinedAlso applies to: 56-56
🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelCreate.test.ts (1)
37-39: Consider using undefined assignment instead of delete operator.The static analysis tool flagged the use of the
deleteoperator, which can impact performance.- delete channel.CancelAfter - delete channel.DestinationTag - delete channel.SourceTag + channel.CancelAfter = undefined + channel.DestinationTag = undefined + channel.SourceTag = undefinedSimilarly for the other
deleteoperations in the file.Also applies to: 45-45, 51-51, 57-57, 63-63
🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 38-38: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMVote.test.ts (3)
37-40: Consider using undefined assignment instead of delete.The static analysis tool suggests avoiding the
deleteoperator which can impact performance.- delete vote.Asset + vote.Asset = undefined const errorMessage = 'AMMVote: missing field Asset' assertInvalid(vote, errorMessage)🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
49-52: Consider using undefined assignment instead of delete.The static analysis tool suggests avoiding the
deleteoperator which can impact performance.- delete vote.Asset2 + vote.Asset2 = undefined const errorMessage = 'AMMVote: missing field Asset2' assertInvalid(vote, errorMessage)🧰 Tools
🪛 Biome (1.9.4)
[error] 49-49: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
61-64: Consider using undefined assignment instead of delete.The static analysis tool suggests avoiding the
deleteoperator which can impact performance.- delete vote.TradingFee + vote.TradingFee = undefined const errorMessage = 'AMMVote: missing field TradingFee' assertInvalid(vote, errorMessage)🧰 Tools
🪛 Biome (1.9.4)
[error] 61-61: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleDelete.test.ts (1)
29-32: Consider using undefined assignment instead of delete.The static analysis tool suggests avoiding the
deleteoperator which can impact performance.- delete tx.OracleDocumentID + tx.OracleDocumentID = undefined const errorMessage = 'OracleDelete: missing field OracleDocumentID' assertInvalid(tx, errorMessage)🧰 Tools
🪛 Biome (1.9.4)
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/trustSet.test.ts (1)
40-42: Consider using undefined assignment instead of delete.The static analysis tool suggests avoiding the
deleteoperator which can impact performance.- delete trustSet.LimitAmount + trustSet.LimitAmount = undefined assertInvalid(trustSet, 'TrustSet: missing field LimitAmount')🧰 Tools
🪛 Biome (1.9.4)
[error] 40-40: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainDelete.test.ts (2)
15-15: Consider using a more specific type thananyWhile using
anyis acceptable for test code, consider using a more specific type for better type safety. You could create an interface or type that matches the expected structure of the transaction object.- let tx: any + let tx: { + TransactionType: string + Account: string + DomainID?: string + [key: string]: unknown + }
31-31: Consider alternatives to thedeleteoperatorThe static analysis tool flagged the use of the
deleteoperator, which can have performance implications. While not critical in test code, you might consider setting properties toundefinedinstead.- delete tx.DomainID + tx.DomainID = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 31-31: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMCreate.test.ts (2)
14-14: Consider using a more specific type thananyWhile using
anyworks for test code, a more specific type would provide better type safety and documentation of the expected structure.- let ammCreate: any + let ammCreate: { + TransactionType: string + Account: string + Amount: string | object + Amount2: object + TradingFee?: number + Sequence: number + [key: string]: unknown + }
36-36: Static analysis warning aboutdeleteoperatorThe static analysis tool flagged multiple uses of the
deleteoperator. While this is not critical in test code, consider alternative approaches for consistency with coding standards.- delete ammCreate.Amount + ammCreate.Amount = undefined - delete ammCreate.Amount2 + ammCreate.Amount2 = undefined - delete ammCreate.TradingFee + ammCreate.TradingFee = undefinedAlso applies to: 48-48, 60-60
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/CredentialAccept.test.ts (1)
17-17: Consider using a more specific type thananyUsing a more specific type would improve type safety and better document the expected structure of the transaction object.
- let credentialAccept: any + let credentialAccept: { + TransactionType: string + Issuer: string | number | undefined + Account: string | number | undefined + CredentialType: string | undefined + Sequence: number + Flags: number + [key: string]: unknown + }packages/xrpl/test/models/NFTokenCancelOffer.test.ts (1)
26-26: Consider using more specific typesThe test objects are cast to
anytype. While this works for test code, consider using more specific types to improve type safety.- } as any + } as { + TransactionType: string + NFTokenOffers?: string[] + Account: string + Fee: string + Sequence: number + Flags: number + }Also applies to: 38-38, 51-51
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (1)
45-45: Consider replacingdeletewithundefinedassignment.The
deleteoperator can impact performance. Consider using undefined assignment instead.- delete tx.XChainBridge + tx.XChainBridge = undefined - delete tx.SignatureReward + tx.SignatureReward = undefined - delete tx.Destination + tx.Destination = undefined - delete tx.Amount + tx.Amount = undefinedAlso applies to: 57-57, 75-75, 87-87
🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/DIDSet.test.ts (1)
52-54: Consider using undefined assignment instead of delete for better performanceStatic analysis suggests avoiding the
deleteoperator for performance reasons.- delete tx.Data - delete tx.DIDDocument - delete tx.URI + tx.Data = undefined + tx.DIDDocument = undefined + tx.URI = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 52-52: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 54-54: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCreate.test.ts (1)
36-36: Consider using undefined assignment instead of delete for better performanceStatic analysis suggests avoiding the
deleteoperator for performance reasons.For example, replace:
- delete escrow.Amount + escrow.Amount = undefinedSimilarly for other delete operations in this file.
Also applies to: 42-42, 84-85, 94-95
🧰 Tools
🪛 Biome (1.9.4)
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDelete.test.ts (1)
37-37: Consider using undefined assignment instead of delete for better performanceStatic analysis suggests avoiding the
deleteoperator for performance reasons.- delete ammDelete.Asset + ammDelete.Asset = undefinedAnd similarly for
ammDelete.Asset2.Also applies to: 49-49
🧰 Tools
🪛 Biome (1.9.4)
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelFund.test.ts (1)
33-33: Consider using undefined assignment instead of delete.The static analysis tool flags multiple uses of the
deleteoperator. While this works, it can impact performance.- delete channel.Expiration + channel.Expiration = undefined - delete channel.Amount + channel.Amount = undefined - delete channel.Channel + channel.Channel = undefinedAlso applies to: 39-39, 45-45
🧰 Tools
🪛 Biome (1.9.4)
[error] 33-33: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts (1)
59-59: Consider using undefined assignment instead of delete.The static analysis tool flags multiple uses of the
deleteoperator. While this works, it can impact performance.- delete tx.Amount + tx.Amount = undefinedApply similar changes to the other
deleteoperations throughout the file.Also applies to: 71-71, 89-89, 107-107, 125-125, 143-143, 161-161, 179-179, 197-197, 215-215, 233-233
🧰 Tools
🪛 Biome (1.9.4)
[error] 59-59: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/payment.test.ts (1)
73-73: Consider alternatives to thedeleteoperator.The
deleteoperator can negatively impact performance. Consider using undefined assignment instead.- delete payment.Amount + payment.Amount = undefined- delete payment.Destination + payment.Destination = undefinedAlso applies to: 83-83
🧰 Tools
🪛 Biome (1.9.4)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMWithdraw.test.ts (1)
89-89: Consider alternatives to thedeleteoperator.The
deleteoperator can impact performance. Consider using undefined assignment instead.- delete withdraw.Asset + withdraw.Asset = undefined- delete withdraw.Asset2 + withdraw.Asset2 = undefinedAlso applies to: 101-101
🧰 Tools
🪛 Biome (1.9.4)
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainClaim.test.ts (1)
44-44: Consider using undefined assignment instead of delete operator.The static analysis tool flagged the use of the
deleteoperator, which can have minor performance implications. While not critical for test code, consider using undefined assignment instead.-delete tx.XChainBridge +tx.XChainBridge = undefinedAlso applies to: 56-56, 68-68, 86-86
🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelClaim.test.ts (1)
46-46: Consider using undefined assignment instead of delete operator.The static analysis tool flagged the use of the
deleteoperator. For consistency with best practices:-delete channel.Channel +channel.Channel = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 46-46: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleSet.test.ts (1)
45-45: Consider using undefined assignment instead of delete operator.Multiple uses of the
deleteoperator were flagged by static analysis. While acceptable in test code, consider using undefined assignment for consistency with best practices:-delete tx.OracleDocumentID +tx.OracleDocumentID = undefinedAlso applies to: 57-57, 114-114, 128-128, 135-135, 142-142, 149-149
🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts (1)
53-53: Consider using undefined assignment instead of delete operator.Multiple uses of the
deleteoperator were flagged by static analysis. While not critical for test code, using undefined assignment would be more consistent with best practices:-delete tx.Amount +tx.Amount = undefinedAlso applies to: 65-65, 83-83, 107-107, 125-125, 137-137, 149-149, 167-167, 179-179
🧰 Tools
🪛 Biome (1.9.4)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainModifyBridge.test.ts (1)
44-44: Consider using undefined assignment instead of delete.Using the
deleteoperator can impact performance. Consider using undefined assignment instead.- delete tx.XChainBridge + tx.XChainBridge = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/ticketCreate.test.ts (1)
29-30: Consider using assignment instead of delete.The
deleteoperator can impact performance. Consider usingundefinedassignment instead.- delete ticketCreate.TicketCount + ticketCreate.TicketCount = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateClaimID.test.ts (3)
44-46: Consider using assignment instead of delete.The
deleteoperator can impact performance. Consider usingundefinedassignment instead.- delete tx.XChainBridge + tx.XChainBridge = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
56-58: Consider using assignment instead of delete.The
deleteoperator can impact performance. Consider usingundefinedassignment instead.- delete tx.SignatureReward + tx.SignatureReward = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
68-70: Consider using assignment instead of delete.The
deleteoperator can impact performance. Consider usingundefinedassignment instead.- delete tx.OtherChainSource + tx.OtherChainSource = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCommit.test.ts (1)
43-43: Consider replacingdeleteoperator withundefinedassignment.The
deleteoperator can impact performance as flagged by static analysis. Consider usingundefinedassignment instead:- delete tx.XChainBridge + tx.XChainBridge = undefined - delete tx.XChainClaimID + tx.XChainClaimID = undefined - delete tx.Amount + tx.Amount = undefinedAlso applies to: 55-55, 73-73
🧰 Tools
🪛 Biome (1.9.4)
[error] 43-43: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/offerCancel.test.ts (1)
47-48: Consider using undefined assignment instead of deleteStatic analysis suggests avoiding the
deleteoperator for performance reasons.- delete offer.OfferSequence + offer.OfferSequence = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 47-47: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMClawback.test.ts (1)
44-47: Performance optimization opportunityStatic analysis suggests avoiding the
deleteoperator for performance reasons. Consider using undefined assignment instead.- delete ammClawback.Amount + ammClawback.Amount = undefinedThis same pattern could be applied to all other instances of
deletein this file (lines 55, 73, and 91).🧰 Tools
🪛 Biome (1.9.4)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainSet.test.ts (1)
47-51: Performance optimization suggestionStatic analysis suggests avoiding the
deleteoperator. Consider using undefined assignment instead.- delete tx.AcceptedCredentials + tx.AcceptedCredentials = undefined🧰 Tools
🪛 Biome (1.9.4)
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (60)
packages/xrpl/HISTORY.md(1 hunks)packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts(1 hunks)packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts(1 hunks)packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts(1 hunks)packages/xrpl/test/models/AMMBid.test.ts(5 hunks)packages/xrpl/test/models/AMMClawback.test.ts(2 hunks)packages/xrpl/test/models/AMMCreate.test.ts(2 hunks)packages/xrpl/test/models/AMMDelete.test.ts(2 hunks)packages/xrpl/test/models/AMMDeposit.test.ts(5 hunks)packages/xrpl/test/models/AMMVote.test.ts(2 hunks)packages/xrpl/test/models/AMMWithdraw.test.ts(5 hunks)packages/xrpl/test/models/CredentialAccept.test.ts(2 hunks)packages/xrpl/test/models/CredentialCreate.test.ts(2 hunks)packages/xrpl/test/models/CredentialDelete.test.ts(2 hunks)packages/xrpl/test/models/DIDDelete.test.ts(2 hunks)packages/xrpl/test/models/DIDSet.test.ts(2 hunks)packages/xrpl/test/models/MPTokenAuthorize.test.ts(6 hunks)packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts(9 hunks)packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts(3 hunks)packages/xrpl/test/models/MPTokenIssuanceSet.test.ts(6 hunks)packages/xrpl/test/models/NFTokenAcceptOffer.test.ts(11 hunks)packages/xrpl/test/models/NFTokenBurn.test.ts(3 hunks)packages/xrpl/test/models/NFTokenCancelOffer.test.ts(4 hunks)packages/xrpl/test/models/NFTokenCreateOffer.test.ts(12 hunks)packages/xrpl/test/models/NFTokenMint.test.ts(9 hunks)packages/xrpl/test/models/NFTokenModify.test.ts(5 hunks)packages/xrpl/test/models/XChainAccountCreateCommit.test.ts(2 hunks)packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts(2 hunks)packages/xrpl/test/models/XChainAddClaimAttestation.test.ts(2 hunks)packages/xrpl/test/models/XChainClaim.test.ts(2 hunks)packages/xrpl/test/models/XChainCommit.test.ts(2 hunks)packages/xrpl/test/models/XChainCreateBridge.test.ts(2 hunks)packages/xrpl/test/models/XChainCreateClaimID.test.ts(2 hunks)packages/xrpl/test/models/XChainModifyBridge.test.ts(2 hunks)packages/xrpl/test/models/accountDelete.test.ts(5 hunks)packages/xrpl/test/models/accountSet.test.ts(2 hunks)packages/xrpl/test/models/baseTransaction.test.ts(15 hunks)packages/xrpl/test/models/checkCancel.test.ts(3 hunks)packages/xrpl/test/models/checkCash.test.ts(6 hunks)packages/xrpl/test/models/checkCreate.test.ts(7 hunks)packages/xrpl/test/models/clawback.test.ts(9 hunks)packages/xrpl/test/models/depositPreauth.test.ts(10 hunks)packages/xrpl/test/models/escrowCancel.test.ts(2 hunks)packages/xrpl/test/models/escrowCreate.test.ts(3 hunks)packages/xrpl/test/models/escrowFinish.test.ts(6 hunks)packages/xrpl/test/models/offerCancel.test.ts(2 hunks)packages/xrpl/test/models/offerCreate.test.ts(8 hunks)packages/xrpl/test/models/oracleDelete.test.ts(2 hunks)packages/xrpl/test/models/oracleSet.test.ts(3 hunks)packages/xrpl/test/models/payment.test.ts(5 hunks)packages/xrpl/test/models/paymentChannelClaim.test.ts(3 hunks)packages/xrpl/test/models/paymentChannelCreate.test.ts(2 hunks)packages/xrpl/test/models/paymentChannelFund.test.ts(2 hunks)packages/xrpl/test/models/permissionedDomainDelete.test.ts(2 hunks)packages/xrpl/test/models/permissionedDomainSet.test.ts(2 hunks)packages/xrpl/test/models/setRegularKey.test.ts(2 hunks)packages/xrpl/test/models/signerListSet.test.ts(5 hunks)packages/xrpl/test/models/ticketCreate.test.ts(1 hunks)packages/xrpl/test/models/trustSet.test.ts(2 hunks)packages/xrpl/test/testUtils.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (6)
packages/xrpl/test/models/MPTokenAuthorize.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/clawback.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/integration/transactions/clawback.test.ts:165-178
Timestamp: 2024-12-06T19:27:11.147Z
Learning: In the integration tests for `clawback.test.ts`, it's acceptable to use `@ts-expect-error` to bypass type checking when verifying ledger entries, and no additional type safety improvements are needed.
packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/models/MPTokenAuthorize.test.ts:60-71
Timestamp: 2024-12-06T18:44:55.095Z
Learning: In the XRPL.js library's TypeScript test file `packages/xrpl/test/models/MPTokenAuthorize.test.ts`, negative test cases for invalid `Account` address format, invalid `Holder` address format, invalid `MPTokenIssuanceID` format, and invalid flag combinations are not necessary.
packages/xrpl/test/models/AMMClawback.test.ts (1)
Learnt from: shawnxie999
PR: XRPLF/xrpl.js#2661
File: packages/xrpl/test/integration/transactions/clawback.test.ts:165-178
Timestamp: 2024-12-06T19:27:11.147Z
Learning: In the integration tests for `clawback.test.ts`, it's acceptable to use `@ts-expect-error` to bypass type checking when verifying ledger entries, and no additional type safety improvements are needed.
🧬 Code Graph Analysis (48)
packages/xrpl/test/models/checkCancel.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/XChainCreateBridge.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCreateBridge.ts (1)
validateXChainCreateBridge(48-56)
packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (2)
packages/xrpl/src/models/transactions/index.ts (2)
NFTokenCreateOfferFlagsInterface(72-72)NFTokenCreateOfferFlags(71-71)packages/xrpl/src/models/utils/index.ts (1)
isFlagEnabled(25-28)
packages/xrpl/test/models/escrowFinish.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/escrowFinish.ts (1)
validateEscrowFinish(49-81)
packages/xrpl/test/models/NFTokenBurn.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenBurn.ts (1)
validateNFTokenBurn(48-52)
packages/xrpl/test/models/oracleDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/oracleDelete.ts (1)
validateOracleDelete(28-32)
packages/xrpl/test/models/paymentChannelCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/paymentChannelCreate.ts (1)
validatePaymentChannelCreate(65-106)
packages/xrpl/test/models/MPTokenAuthorize.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenAuthorize.ts (1)
validateMPTokenAuthorize(63-67)
packages/xrpl/test/models/trustSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/trustSet.ts (1)
validateTrustSet(137-156)
packages/xrpl/test/models/payment.test.ts (3)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/payment.ts (1)
validatePayment(173-212)packages/xrpl/src/models/transactions/index.ts (1)
PaymentFlags(88-88)
packages/xrpl/test/models/paymentChannelClaim.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/paymentChannelClaim.ts (1)
validatePaymentChannelClaim(149-183)
packages/xrpl/test/models/DIDSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/DIDSet.ts (1)
validateDIDSet(31-49)
packages/xrpl/test/models/oracleSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/oracleSet.ts (1)
validateOracleSet(75-198)
packages/xrpl/test/models/paymentChannelFund.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/CredentialCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/CredentialCreate.ts (1)
validateCredentialCreate(47-59)
packages/xrpl/test/models/XChainModifyBridge.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainModifyBridge.ts (1)
validateXChainModifyBridge(69-77)
packages/xrpl/test/models/offerCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/offerCreate.ts (1)
validateOfferCreate(117-143)
packages/xrpl/test/models/NFTokenCancelOffer.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenCancelOffer.ts (1)
validateNFTokenCancelOffer(41-51)
packages/xrpl/test/models/permissionedDomainSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/permissionedDomainSet.ts (1)
validatePermissionedDomainSet(33-54)
packages/xrpl/test/models/escrowCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/escrowCreate.ts (1)
validateEscrowCreate(58-95)
packages/xrpl/test/models/CredentialAccept.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/CredentialAccept.ts (1)
validateCredentialAccept(36-44)
packages/xrpl/test/models/NFTokenAcceptOffer.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenAcceptOffer.ts (1)
validateNFTokenAcceptOffer(98-110)
packages/xrpl/test/models/DIDDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (1)
assertTxIsValid(66-69)packages/xrpl/src/models/transactions/DIDDelete.ts (1)
validateDIDDelete(18-20)
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts (1)
validateMPTokenIssuanceSet(66-86)
packages/xrpl/test/models/NFTokenModify.test.ts (3)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/index.ts (1)
validateNFTokenModify(79-79)packages/xrpl/src/models/transactions/NFTokenModify.ts (1)
validateNFTokenModify(52-67)
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainAccountCreateCommit.ts (1)
validateXChainAccountCreateCommit(57-69)
packages/xrpl/test/models/AMMVote.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMVote.ts (1)
validateAMMVote(39-71)
packages/xrpl/test/models/checkCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/checkCreate.ts (1)
validateCheckCreate(57-82)
packages/xrpl/test/models/checkCash.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/checkCash.ts (1)
validateCheckCash(40-72)
packages/xrpl/test/models/AMMDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/AMMDelete.ts (1)
validateAMMDelete(37-55)
packages/xrpl/test/testUtils.ts (1)
packages/xrpl/src/errors.ts (1)
ValidationError(156-156)
packages/xrpl/test/models/setRegularKey.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/XChainClaim.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainClaim.ts (1)
validateXChainClaim(63-79)
packages/xrpl/test/models/XChainCommit.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCommit.ts (1)
validateXChainCommit(62-76)
packages/xrpl/test/models/clawback.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/clawback.ts (1)
validateClawback(43-70)
packages/xrpl/test/models/depositPreauth.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/depositPreauth.ts (1)
validateDepositPreauth(45-87)
packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts (1)
validateMPTokenIssuanceCreate(124-180)
packages/xrpl/test/models/accountDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/accountDelete.ts (1)
validateAccountDelete(47-60)
packages/xrpl/test/models/offerCancel.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/XChainCreateClaimID.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainCreateClaimID.ts (1)
validateXChainCreateClaimID(46-54)
packages/xrpl/test/models/NFTokenCreateOffer.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (1)
validateNFTokenCreateOffer(123-161)
packages/xrpl/test/models/CredentialDelete.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/CredentialDelete.ts (1)
validateCredentialDelete(39-55)
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/XChainAddAccountCreateAttestation.ts (1)
validateXChainAddAccountCreateAttestation(89-123)
packages/xrpl/test/models/NFTokenMint.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/NFTokenMint.ts (1)
validateNFTokenMint(146-180)
packages/xrpl/test/models/ticketCreate.test.ts (1)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)
packages/xrpl/test/models/accountSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/accountSet.ts (1)
validateAccountSet(175-225)
packages/xrpl/test/models/signerListSet.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/signerListSet.ts (1)
validateSignerListSet(39-88)
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (2)
packages/xrpl/test/testUtils.ts (2)
assertTxIsValid(66-69)assertTxValidationError(78-85)packages/xrpl/src/models/transactions/MPTokenIssuanceDestroy.ts (1)
validateMPTokenIssuanceDestroy(29-34)
🪛 Biome (1.9.4)
packages/xrpl/test/models/XChainCreateBridge.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleDelete.test.ts
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelCreate.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 38-38: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 51-51: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 63-63: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/trustSet.test.ts
[error] 40-40: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/payment.test.ts
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 83-83: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelClaim.test.ts
[error] 46-46: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/DIDSet.test.ts
[error] 52-52: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 54-54: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/oracleSet.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 114-114: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 128-128: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 135-135: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 142-142: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 149-149: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/paymentChannelFund.test.ts
[error] 33-33: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 39-39: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainModifyBridge.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainSet.test.ts
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts
[error] 53-53: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 65-65: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 83-83: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 107-107: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 125-125: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 137-137: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 149-149: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 167-167: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 179-179: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCancel.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 42-42: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMWithdraw.test.ts
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 101-101: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMBid.test.ts
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 80-80: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/escrowCreate.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 42-42: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 84-84: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 85-85: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 57-57: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 75-75: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 87-87: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMVote.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 49-49: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 61-61: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMCreate.test.ts
[error] 36-36: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 48-48: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 60-60: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDelete.test.ts
[error] 37-37: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 49-49: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMDeposit.test.ts
[error] 78-78: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 90-90: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainClaim.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 86-86: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCommit.test.ts
[error] 43-43: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 55-55: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/permissionedDomainDelete.test.ts
[error] 31-31: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/offerCancel.test.ts
[error] 47-47: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainCreateClaimID.test.ts
[error] 44-44: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 56-56: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 68-68: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts
[error] 59-59: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 71-71: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 89-89: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 107-107: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 125-125: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 143-143: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 161-161: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 179-179: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 197-197: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 215-215: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 233-233: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/ticketCreate.test.ts
[error] 29-29: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
packages/xrpl/test/models/AMMClawback.test.ts
[error] 45-45: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 55-55: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 73-73: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
[error] 91-91: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: snippets (22.x)
- GitHub Check: snippets (18.x)
- GitHub Check: browser (18.x)
- GitHub Check: snippets (20.x)
🔇 Additional comments (186)
packages/xrpl/test/models/escrowCancel.test.ts (3)
2-6: Good refactoring to improve test readability and consistency.The introduction of the helper functions
assertValidandassertInvalidwrapping the common utilities makes the tests more concise and easier to read. This standardized approach will make tests more maintainable across the codebase.
14-14: Type declaration helps with clarity.Adding the explicit
anytype for thecancelvariable improves code clarity, even though TypeScript could infer the type.
25-27: Test readability improved with helper functions.Using the specialized assertion helpers makes the test assertions more concise and focused on what's being tested rather than the mechanics of validation and error handling.
Also applies to: 29-33, 35-39, 41-45, 47-51, 53-57
packages/xrpl/test/models/escrowFinish.test.ts (3)
2-6: Well-structured helper function implementation.The introduction of utility functions from
testUtilsand the local helper functionsassertValidandassertInvalidprovides a clean abstraction that simplifies test assertions. This approach improves readability and maintainability by standardizing the validation pattern across tests.
14-14: Explicit type annotation improves clarity.Explicitly typing
escrowasanyimproves type clarity, which is good practice especially when working with test fixtures that may have dynamic properties.
31-31: Consistent use of helper functions across all test cases.The consistent replacement of direct assertion calls with the helper functions
assertValidandassertInvalidacross all test cases streamlines the test code and makes it more maintainable.Also applies to: 39-39, 45-45, 51-51, 57-57, 63-63, 69-69, 78-78, 97-97, 105-105, 116-116, 128-128
packages/xrpl/test/models/baseTransaction.test.ts (3)
6-9: Direct implementation of assertion helpers.Unlike the other files that use imported utility functions, this file implements the helpers directly with
assert.doesNotThrowandassert.throws. Note that this approach doesn't validate against the genericvalidatefunction like the imported utilities do. This inconsistency might be intentional for base transaction tests.
18-18: Explicit type annotation for test fixture.Adding the explicit type annotation
: anyto the test fixture improves type clarity and consistency with other test files.
64-64: Consistent use of helper functions simplifies assertions.The consistent use of
assertValidandassertInvalidhelper functions across all test cases improves code readability and maintainability.Also applies to: 73-73, 83-83, 93-93, 103-103, 113-115, 126-126, 136-136, 146-148, 159-159, 169-169, 183-183, 200-200, 209-209
packages/xrpl/test/models/XChainCreateBridge.test.ts (3)
2-7: Helper functions improve test structure.The introduction of utility functions and local helper wrappers standardizes the test assertions, following the same pattern used across other transaction model tests.
15-15: Explicit type annotation for test fixture.Explicitly typing
txasanyimproves clarity and consistency with other test files.
40-40: Consistent use of helper functions streamlines test assertions.The consistent use of
assertValidandassertInvalidhelper functions across all test cases simplifies the test code.Also applies to: 46-46, 52-52, 58-58, 64-64, 70-72
packages/xrpl/test/models/paymentChannelCreate.test.ts (3)
2-7: Helper functions standardize validation approach.The introduction of utility functions and local helper wrappers provides a consistent pattern for asserting validation success and failure across all transaction model tests.
15-15: Explicit type annotation improves clarity.Explicitly typing
channelasanyimproves type clarity and consistency with other test files.
33-33: Consistent use of helper functions simplifies validation assertions.The consistent replacement of direct assertion calls with the helper functions across all test cases streamlines the test code.
Also applies to: 41-41, 47-47, 53-53, 59-59, 65-65, 71-71, 77-77, 83-83, 89-89, 95-95, 101-101
packages/xrpl/test/models/AMMVote.test.ts (3)
2-6: Well-structured helper functions introduced for test standardization.The introduction of
assertValidandassertInvalidhelper functions provides a cleaner abstraction for validation tests. This approach reduces code duplication and improves readability by encapsulating the validation logic.
14-14: Good type clarification.Adding the explicit
anytype for thevotevariable improves code clarity and aligns with TypeScript best practices by making implicit types explicit.
33-33: Simplified test assertion.Using the new
assertValidhelper function makes the test more concise while still maintaining the same validation checks.packages/xrpl/test/models/NFTokenBurn.test.ts (3)
1-6: Well-implemented helper functions for consistent test structure.The use of
assertValidandassertInvalidhelper functions creates a consistent testing pattern across the codebase, which improves maintainability. This matches the pattern introduced in the AMMVote test file.
27-27: Simplified validation check.Using the
assertValidhelper function streamlines the test while maintaining the same validation coverage.
39-39: Clean error validation.Using
assertInvalidsimplifies error validation while still ensuring both the specific validator and generic validate function throw the expected error.packages/xrpl/test/models/oracleDelete.test.ts (2)
2-6: Consistent helper function implementation.The utility functions follow the same pattern as in other test files, providing a unified approach to transaction validation testing.
14-14: Explicit type annotation.Adding the explicit
anytype for thetxvariable improves code clarity and follows good TypeScript practices.packages/xrpl/test/models/trustSet.test.ts (2)
2-6: Consistent helper functions for standardized testing.The helper functions follow the same pattern as in other test files, maintaining consistency across the codebase.
14-14: Appropriate type annotation.The explicit typing of
trustSetasanyimproves code clarity and type safety.packages/xrpl/test/models/permissionedDomainDelete.test.ts (2)
2-7: Good implementation of test utilities for consistencyThe addition of
assertTxIsValidandassertTxValidationErrorimports along with the local helper functionsassertValidandassertInvalidis a great refactoring choice. This approach centralizes validation logic and reduces duplication across test files.The helper functions make the test code more readable and maintainable by encapsulating the validation logic and error checking in a concise way.
27-27: Good use of helper functions for validation assertionsReplacing direct assertion calls with the helper functions
assertValidandassertInvalidmakes the tests much cleaner and more consistent. The refactoring helps standardize how validation is tested across the suite.Also applies to: 33-33, 39-39
packages/xrpl/test/models/AMMCreate.test.ts (2)
2-6: Good implementation of test utilitiesThe addition of
assertTxIsValidandassertTxValidationErrorimports along with the local helper functions is consistent with the refactoring pattern seen across test files. This standardization helps improve code maintainability.
32-32: Consistent use of helper functionsThe consistent replacement of direct assertion calls with helper functions improves readability and makes the validation pattern uniform. This is a good example of the "Don't Repeat Yourself" (DRY) principle.
Also applies to: 38-38, 44-44, 50-50, 56-56, 62-62, 68-68, 74-74, 80-80
packages/xrpl/test/models/CredentialAccept.test.ts (2)
4-9: Good implementation of test utilitiesThe addition of specialized assertion utilities and local helper functions follows the consistent pattern used throughout the codebase refactoring. This approach centralizes validation logic and improves maintenance.
31-31: Consistent use of helper functionsThe refactoring to use helper functions for validation assertions is consistent with the approach seen in other test files. This uniformity makes the codebase easier to understand and maintain.
Also applies to: 37-37, 43-43, 49-49, 55-55, 61-61, 68-68, 75-75, 82-82
packages/xrpl/test/models/NFTokenCancelOffer.test.ts (2)
1-7: Good implementation of test utilitiesThe addition of import for the validator function and test utilities, along with the local helper functions, creates a consistent pattern for transaction validation testing. This approach encapsulates validation logic and makes tests more readable.
28-28: Consistent use of helper functionsThe replacement of direct validation calls with helper functions follows the same pattern as other test files, ensuring consistency across the test suite. This standardization makes the code easier to maintain and understand.
Also applies to: 40-40, 53-53
packages/xrpl/test/models/CredentialCreate.test.ts (3)
4-9: Well-structured helper functions for validation testing.The introduction of helper functions
assertValidandassertInvalidis a clean approach that improves readability by abstracting the validation logic.
17-17: Appropriate type annotation for test variable.The explicit
anytype for thecredentialCreatevariable improves type clarity, which is good practice for test code.
33-33: Consistent use of helper functions across test cases.Replacing the direct validation calls with the helper functions makes the test more concise and consistent, reducing duplication and improving maintainability.
Also applies to: 39-39, 45-45, 51-51, 57-57, 63-63, 70-70, 77-77, 84-84, 90-90, 96-96, 102-102, 108-108, 114-114
packages/xrpl/test/models/XChainAccountCreateCommit.test.ts (3)
4-7: Well-structured helper functions for validation testing.The helper functions
assertValidandassertInvalidnicely encapsulate the validation logic and improve code readability.
15-15: Appropriate type annotation for test variable.The explicit
anytype for thetxvariable improves type clarity in test code.
41-41: Consistent use of helper functions across test cases.Using the helper functions consistently throughout the test suite improves readability and maintainability.
Also applies to: 47-47, 53-53, 59-62, 68-71, 77-77, 83-83, 89-89, 95-95
packages/xrpl/test/models/checkCancel.test.ts (2)
4-6: Cleaner validation helpers with simplified function syntax.The helper functions use a concise arrow function syntax, which is consistent with modern JavaScript/TypeScript practices and improves readability.
22-22: Consistent use of helper functions in test assertions.The test cases have been updated to use the new helper functions, making the code more maintainable and consistent with the rest of the codebase.
Also applies to: 32-32
packages/xrpl/test/models/NFTokenAcceptOffer.test.ts (2)
1-7: Well-structured helpers with proper imports.The code properly imports the specific validation function and test utilities, then wraps them in concise helper functions that improve test readability.
30-30: Consistent use of helper functions across all test cases.All test cases now use the helper functions consistently, which reduces code duplication and improves maintainability. The multiline formatting for complex assertions is also well-structured and readable.
Also applies to: 43-43, 55-58, 72-75, 89-92, 106-106, 121-121, 136-139, 154-157, 172-172
packages/xrpl/test/models/DIDSet.test.ts (3)
2-6: Helper functions improve consistency and readabilityThe introduction of
assertTxIsValidandassertTxValidationErrorutilities along with localassertValidandassertInvalidwrapper functions is a good refactoring. This approach centralizes validation logic and reduces duplication across test cases.
14-14: Explicit typing adds clarityExplicitly typing
txasanyimproves code clarity and maintainability.
30-30: Simplified test assertionsThe new assertion pattern nicely streamlines the test code while maintaining the same validation logic. These helpers appropriately encapsulate both the specific and generic validators.
Also applies to: 36-36, 42-42, 48-48, 56-59
packages/xrpl/test/models/escrowCreate.test.ts (3)
2-6: Consistent helper function pattern improves test organizationThe use of
assertTxIsValidandassertTxValidationErrorwith local wrapper functions follows the same consistent pattern adopted across test files, improving code readability and maintainability.
14-14: Explicit typing clarifies variable usageExplicitly typing
escrowasanyimproves code clarity.
32-32: Streamlined test assertions maintain validation integrityThe refactored assertions properly maintain the validation logic while simplifying the code structure. Each test case appropriately uses the helper functions to verify validation behavior.
Also applies to: 38-38, 44-44, 50-50, 56-56, 62-62, 68-68, 74-74, 80-80, 87-90, 97-100
packages/xrpl/test/models/AMMDelete.test.ts (3)
2-6: Consistent helper function pattern maintains testing standardsThe adoption of the
assertTxIsValidandassertTxValidationErrorutility functions with local wrappers follows the same pattern as other test files, creating a standardized testing approach.
14-14: Explicit typing enhances code clarityExplicitly typing
ammDeleteasanyimproves clarity about the variable's intended usage.
33-33: Simplified assertions maintain validation integrityThe refactored assertions provide a clear and consistent pattern for verifying validation logic. The named constants for error messages add clarity to the test cases.
Also applies to: 39-39, 45-45, 51-51, 57-57
packages/xrpl/test/models/checkCreate.test.ts (2)
2-6: Consistent helper pattern improves test readabilityUsing the
assertTxIsValidandassertTxValidationErrorutilities with local wrapper functions follows the standardized pattern adopted across test files, improving readability and maintenance.
27-27: Streamlined test assertions maintain validation correctnessThe refactored assertions effectively test the same validation logic while reducing code duplication. Each test case now follows a consistent pattern that clearly communicates its intent.
Also applies to: 43-43, 59-59, 75-77, 94-94, 109-109
packages/xrpl/test/models/checkCash.test.ts (6)
2-6: Good refactoring with reusable test assertions.The introduction of utility functions
assertTxIsValidandassertTxValidationErroralong with the local helpersassertValidandassertInvalidcreates a cleaner and more consistent approach to transaction validation testing. This pattern eliminates duplication and makes the test cases more readable.
24-24: LGTM: Simplified test assertion.Replaced direct assertion calls with the helper function for cleaner code.
35-35: LGTM: Consistent error assertion pattern.The use of the
assertInvalidhelper provides a consistent way to check validation errors.
47-47: LGTM: Consistent validation pattern.Maintains the same validation behavior while improving code readability.
60-63: LGTM: Improved test readability.Using the helper function with proper formatting for longer error messages improves readability.
75-75: LGTM: Consistent test pattern.Follows the established pattern for validation error assertions.
packages/xrpl/test/models/paymentChannelFund.test.ts (5)
2-7: Good implementation of reusable test utilities.The introduction of helper functions improves test consistency and reduces duplication across test cases.
15-15: LGTM: Explicit type annotation.Adding explicit type annotation for
channelasanyimproves code clarity.
29-29: LGTM: Simplified valid transaction testing.Replacing direct assertion with the helper function improves code consistency.
35-35: LGTM: Consistent validation approach.Maintains test behavior while improving code readability.
41-41: LGTM: Consistent error validation patterns.All error assertions follow the same pattern, making the code more maintainable.
Also applies to: 47-47, 53-53, 59-59, 65-65
packages/xrpl/test/models/XChainAddAccountCreateAttestation.test.ts (4)
2-11: Good implementation of reusable test utilities.The introduction of helper functions with clear formatting improves readability and consistency across test cases.
19-19: LGTM: Explicit type annotation.Adding explicit type annotation for
txasanyimproves code clarity.
55-55: LGTM: Simplified valid transaction testing.Replacing direct assertion with the helper function improves code consistency.
61-62: LGTM: Consistent error validation patterns.All error validation assertions now follow a consistent pattern, improving readability and maintainability of the test suite.
Also applies to: 67-68, 73-76, 82-85, 91-94, 100-103, 109-112, 118-121, 127-130, 136-139, 145-148, 154-157, 163-166, 172-175, 181-184, 190-193, 199-202, 208-211, 217-220, 226-229, 235-238, 244-247
packages/xrpl/src/models/transactions/NFTokenCreateOffer.ts (2)
149-155: Improved flag handling with null/undefined safety.The changes enhance the Flags handling by:
- Providing a default value of
0when Flags is undefined- Supporting both numeric and interface-based flag representations
- Adding null safety with defaults when checking flag values
This makes the validation more robust and less prone to runtime errors.
156-156: Simplified conditional check.Using the calculated boolean value directly for the conditional statement improves code readability.
packages/xrpl/test/models/NFTokenModify.test.ts (3)
1-9: Good refactoring of imports and introduction of helper functions.The code now uses the more standardized
stringToHexfrom@xrplf/isomorphicand introduces helper functions to simplify test assertions. This follows good DRY principles by wrapping the utility functions fromtestUtilsin more concise helpers specific to this test file.
27-27: Updated to use standard utility function.Correctly updated to use the imported
stringToHexfunction, maintaining consistent utility usage across the codebase.
30-30: Improved test assertions using helper functions.The refactoring to use
assertValidandassertInvalidhelper functions makes the tests more readable and maintainable. This standardized approach ensures consistent validation across test files and reduces code duplication.Also applies to: 41-41, 54-54, 67-67
packages/xrpl/test/models/payment.test.ts (3)
3-9: Clean implementation of shared test utilities.Good refactoring to import
assertTxIsValidandassertTxValidationErrorfromtestUtilsand create local helper functions. This makes test assertions more consistent and reduces code duplication across the test suite.
17-17: Improved variable naming.Renamed variable from likely
paymentTransactiontopaymentprovides better semantic clarity and consistency with other test files.
43-44: Streamlined validation assertions.Replaced direct validation calls with the helper functions, making the test code more readable and maintainable. This approach ensures consistent validation across the codebase.
Also applies to: 56-56, 69-70, 74-74, 79-79, 84-85, 89-90, 94-95, 99-99, 104-105, 109-110, 114-115, 119-120, 124-125, 130-131, 136-137, 141-142
packages/xrpl/test/models/accountSet.test.ts (3)
2-6: Effective implementation of test utility functions.Good adoption of the
assertTxIsValidandassertTxValidationErrorutilities with local helper functions, improving code readability and consistency with other test files in the codebase.
14-14: Improved variable naming.Renaming from
accounttotxprovides better semantic clarity and aligns with the convention used in other test files.
30-31: Successfully refactored test assertions.The test cases now use the helper functions
assertValidandassertInvalid, which makes the test code more concise and maintainable. This follows the consistent pattern applied across various test files in this PR.Also applies to: 35-36, 40-41, 45-46, 50-51, 55-56, 60-61, 65-66, 70-71, 75-76
packages/xrpl/test/models/AMMWithdraw.test.ts (3)
3-9: Well-structured test utilities implementation.Good refactoring to use the centralized
assertTxIsValidandassertTxValidationErrorutilities and create local helper functions for cleaner test assertions.
22-22: Explicit typing improves code clarity.Explicitly typing
withdrawasanyclarifies the intention and aligns with TypeScript best practices, even though the type is inferred from the assignment.
43-43: Consistent use of assertion helpers across tests.Successfully replaced direct validation calls with helper functions, making the tests more readable and consistent with the rest of the codebase.
Also applies to: 49-49, 60-60, 67-67, 74-74, 80-80, 85-85, 91-91, 97-97, 103-103, 109-109, 119-119, 125-125, 132-132, 138-138, 145-145, 152-152
packages/xrpl/test/models/XChainClaim.test.ts (3)
2-6: Good centralization of validation logic.The refactoring effectively centralizes the validation logic using utility functions from
testUtils, creating local helpers that improve code readability and maintainability.
14-14: Adding explicit typing improves code clarity.Explicitly typing
txasanyclearly communicates the variable type, though in a future refactoring consider using a more specific type if possible.
40-40: Test assertions are now more consistent and concise.The use of helper functions
assertValidandassertInvalidmakes test assertions more readable, consistent, and maintainable across the test suite.Also applies to: 46-46, 52-52, 58-58, 64-64, 70-70, 76-76, 82-82, 88-88, 94-94
packages/xrpl/test/models/paymentChannelClaim.test.ts (3)
2-7: Good use of utility functions for consistent testing.The refactoring nicely leverages
assertTxIsValidandassertTxValidationErrorutilities, wrapping them in descriptive local helper functions that improve code readability.
15-15: Explicit typing improves code clarity.Adding explicit typing to
channelasanymakes the variable type clear, enhancing code readability.
33-33: Consistent test assertion pattern applied.All test assertions now follow a consistent pattern using the helper functions, which simplifies the code and improves maintainability.
Also applies to: 42-42, 48-48, 54-54, 60-60, 66-66, 72-72, 78-78
packages/xrpl/test/models/oracleSet.test.ts (3)
4-8: Well-structured helper functions improve test readability.The addition of
assertValidandassertInvalidhelper functions provides a clean abstraction for validation testing, making the code more readable and maintainable.
16-16: Explicit typing enhances code clarity.Explicitly typing
txasanyclearly communicates the variable type, which is good for code readability.
41-41: Consistent test assertions improve maintainability.The refactoring to use consistent assertion patterns across all test cases significantly improves code maintainability and readability.
Also applies to: 47-47, 53-53, 59-59, 65-65, 71-71, 77-77, 89-89, 96-96, 110-110, 117-117, 124-124, 131-131, 138-138, 145-145, 152-152, 159-159, 165-165, 173-173, 179-179, 185-185, 191-191
packages/xrpl/test/models/XChainAddClaimAttestation.test.ts (3)
2-7: Good refactoring to centralized validation utilities.The introduction of utility functions from
testUtilsand local helper wrappers creates a more consistent validation pattern across the test suite.
15-15: Explicit typing improves code clarity.Explicitly typing
txasanymakes the intended type clear, which enhances code readability.
49-49: Consistent validation assertions improve test maintainability.Using the helper functions consistently across all test cases significantly improves code maintainability and readability. The multiline assertions with proper indentation ensure clear error messages.
Also applies to: 55-55, 61-61, 67-70, 76-79, 85-88, 94-97, 103-103, 109-112, 118-121, 127-127, 133-133, 139-139, 145-145, 151-154, 160-163, 169-169, 175-175, 181-181, 187-187
packages/xrpl/test/models/signerListSet.test.ts (5)
2-7: Good refactoring approach with helper functionsThe introduction of
assertValidandassertInvalidhelper functions makes the test code more readable and maintainable by encapsulating the validation logic.
15-15: Explicit typing asanyis appropriate hereSince this is test code and the variable is used for various validation scenarios with different properties, the
anytype is reasonable.
48-48: Simplified validation assertionReplaced direct validation calls with the helper function, improving readability while maintaining the same functionality.
54-54: Consistent error validation patternUsing
assertInvalidcreates a consistent pattern for error validation throughout the tests.
60-63: Multiline assertion refactored effectivelyThe multiline assertion is properly refactored to use the helper function while maintaining readability.
packages/xrpl/test/models/AMMBid.test.ts (4)
2-6: Good use of helper functions for test assertionsCreating local helpers
assertValidandassertInvalidthat wrap the imported utilities provides a concise way to handle validation in test cases.
14-14: Appropriate use ofanytype for test objectThe
anytype gives flexibility for testing various scenarios with different properties.
64-64: Consistent application of helper functionsHelper functions are consistently applied throughout the test file, making test assertions more readable and maintainable.
Also applies to: 70-70, 76-76, 82-82, 88-88, 94-94, 100-100, 111-111, 117-117, 125-125, 133-133, 141-141, 151-151, 162-162
60-60:❌ Incorrect review comment
Consider addressing static analysis warning about delete operator
While not directly part of your changes, the static analysis tool flags potential performance issues with the
deleteoperator on lines 68 and 80.Biome suggests using undefined assignment instead:
- delete bid.Asset + bid.Asset = undefined
🏁 Script executed:
#!/bin/bash # Check if delete operator is used elsewhere in test files and how it's handled rg -g "*.test.ts" "delete \w+\." --count packages/xrpl/test/Length of output: 1832
Ignore performance warnings for
deletein testsThe
deleteoperator is used widely across our test suite (e.g. 30+ occurrences) and has no meaningful impact on test‑execution performance. There’s no need to refactor these tests to usefoo = undefined. If you’d like to silence the linter, you can locally disable the rule:// eslint-disable-next-line no-delete delete bid.AssetLikely an incorrect or invalid review comment.
packages/xrpl/test/models/depositPreauth.test.ts (5)
3-10: Good refactoring of import structure and helper functionsThe imports are properly organized and the helper functions effectively encapsulate the validation logic.
18-18: Appropriate use ofanytype for flexible test objectUsing
anyfor the test object is appropriate in test code where properties are dynamically added and removed.
36-36: Simplified positive validation testsThe
assertValidhelper function makes the positive validation tests more concise and readable.Also applies to: 41-41, 46-46, 51-51
60-70: Effectively refactored multiple validation testsThe multiple validation tests in this section are refactored consistently while maintaining the test coverage.
104-107: Previous duplication issue fixedThe duplication issue identified in a previous review has been successfully addressed.
packages/xrpl/test/models/AMMDeposit.test.ts (5)
3-9: Consistent approach to refactoringThe same refactoring pattern is applied here with imports and helper functions, maintaining consistency across the codebase.
22-22: Appropriate type annotationUsing
anytype for the test object is appropriate given its dynamic nature in tests.
43-43: Simplified positive validation testsAll positive validation tests are refactored consistently using the
assertValidhelper function.Also applies to: 49-49, 60-60, 67-67, 74-74
80-80: Consider addressing static analysis warning about delete operatorSimilar to the AMMBid.test.ts file, the static analysis tool flags potential performance issues with the
deleteoperator on lines 78 and 90.Biome suggests using undefined assignment instead:
- delete deposit.Asset + deposit.Asset = undefinedNOTE: If you decide to address this, the change should be applied consistently across all test files that use the delete operator.
86-86: Consistent validation error handlingError validation is consistently implemented using the
assertInvalidhelper function throughout the file.Also applies to: 92-92, 98-98, 103-103, 113-113, 119-119, 126-126, 132-132, 139-139, 146-146
packages/xrpl/test/models/offerCreate.test.ts (3)
2-6: LGTM! Good refactoring with helper functions.The introduction of utility functions and local helpers significantly improves the test's readability and maintainability. This approach centralizes validation logic, reduces code duplication, and creates a consistent pattern for testing.
36-36: Good standardization of assertion patterns.Replacing direct assertions with the helper functions provides consistency across all positive test cases while maintaining the same validation logic.
Also applies to: 59-59, 86-86
110-110: Improved error validation approach.The refactored error validation is more readable and ensures consistent error checking behavior across all negative test cases.
Also applies to: 134-134, 154-154, 178-178
packages/xrpl/test/models/accountDelete.test.ts (3)
2-7: LGTM! Consistent application of the refactoring pattern.The helper functions provide a clean abstraction for validation assertions, following the same pattern as other refactored test files.
15-15: Good type annotation.Explicit type annotation improves code clarity and TypeScript type checking.
32-32: Standardized validation approach across test cases.The consistent use of helper functions across all test cases improves readability and maintainability while preserving the original validation logic.
Also applies to: 38-38, 44-44, 50-50, 58-58, 76-76, 83-83, 93-93, 104-104
packages/xrpl/test/models/MPTokenIssuanceDestroy.test.ts (2)
1-7: LGTM! Clean implementation of the helper pattern.The refactoring maintains the same validation logic while making the code more maintainable through abstraction of common validation patterns.
24-24: Improved validation assertions.The new assertion pattern makes the code more readable and ensures consistent validation behavior between the transaction-specific validator and the generic validator.
Also applies to: 33-35
packages/xrpl/test/models/XChainModifyBridge.test.ts (2)
2-7: LGTM! Consistent application of the helper pattern.The refactoring follows the same helper function pattern as the other files, providing consistency across the test suite.
40-40: Improved validation assertions.The consistent use of helper functions across all test cases improves readability and maintainability while preserving the original validation logic.
Also applies to: 46-46, 52-52, 58-58, 64-65
packages/xrpl/test/models/MPTokenAuthorize.test.ts (6)
1-8: Well-structured helper functions for validation testing.The refactoring introduces local helper functions
assertValidandassertInvalidthat wrap the utilities fromtestUtils, making the tests more concise and readable. The imports have been appropriately scoped to include only what's needed.
25-25: Improved test readability.Replacing direct validation calls with the
assertValidhelper function makes the test more concise and consistent with the broader refactoring pattern.
34-34: Consistent validation approach.The change ensures both the specific validator and generic validation are checked consistently, improving test reliability.
43-43: Improved test readability.Same improvement pattern as the previous assertion replacements.
53-53: Improved test readability.Same improvement pattern as the previous assertion replacements.
62-62: Improved test readability.Using
assertInvalidprovides a cleaner way to test for validation errors with the expected message.packages/xrpl/test/models/ticketCreate.test.ts (4)
2-6: Well-structured helper functions for validation testing.The introduction of helper functions improves test readability and ensures consistent validation across the test suite.
14-14: Added explicit type annotation.Adding the
anytype to theticketCreatevariable makes the type intention clear, which is good for code readability.
25-25: Improved test readability.Using the
assertValidhelper function makes the test more concise and maintains consistency.
35-35: Improved test readability and consistency.Using the
assertInvalidhelper function improves readability and ensures consistent validation across all test cases.Also applies to: 40-42, 48-50, 56-58
packages/xrpl/test/models/CredentialDelete.test.ts (4)
4-9: Well-structured helper functions for validation testing.The helper functions follow the established pattern across the codebase refactoring, making tests more consistent and readable.
17-17: Added explicit type annotation.Adding the
anytype annotation to thecredentialDeletevariable improves code clarity.
32-32: Improved test readability.Using the
assertValidhelper function ensures the validation logic is consistent.
38-38: Consistent validation error handling.Replacing direct assertions with the
assertInvalidhelper function ensures consistent validation error handling across all test cases.Also applies to: 44-44, 50-50, 56-56, 64-64, 70-70, 77-77, 84-84, 91-91
packages/xrpl/test/models/XChainCreateClaimID.test.ts (6)
2-7: Well-structured helper functions for validation testing.The helper functions maintain consistency with the broader refactoring pattern and improve test readability.
15-15: Added explicit type annotation.Adding the
anytype annotation to thetxvariable improves code clarity.
40-40: Improved test readability.Using the
assertValidhelper function makes the test more concise and maintains consistency.
52-52: Improved test readability and consistency.Using the
assertInvalidhelper function improves readability and ensures consistent validation.
64-64: Improved test readability and consistency.Using the
assertInvalidhelper function ensures consistent validation.
76-76: Improved test readability and consistency.Using the
assertInvalidhelper function ensures consistent validation.packages/xrpl/test/models/XChainCommit.test.ts (3)
2-6: Improved test organization with helper functions.The introduction of utility functions
assertTxIsValidandassertTxValidationErroralong with the local wrapper functionsassertValidandassertInvalidcreates a more maintainable and consistent approach to validation testing.
14-14: Good explicit typing.Explicitly typing
txasanyimproves code clarity and sets clear expectations about the variable type.
39-39: Streamlined test assertions with helper functions.Replacing direct assertion calls with the helper functions makes the tests more concise and readable while maintaining the same validation logic.
Also applies to: 45-45, 51-51, 57-57, 63-63, 69-69, 75-75, 81-81
packages/xrpl/test/models/DIDDelete.test.ts (3)
2-4: Good use of helper function for concise test assertions.The introduction of the
assertValidhelper function improves code readability and consistency with other test files.
12-12: Good explicit typing.Explicitly typing
txasanyimproves code clarity and sets clear expectations about the variable type.
25-25: Streamlined test assertion with helper function.Using the helper function makes the test more concise and consistent with the rest of the test suite.
packages/xrpl/test/models/setRegularKey.test.ts (4)
2-7: Improved test organization with helper functions.The introduction of utility functions and local wrapper functions creates a more maintainable and consistent approach to validation testing.
15-15: Improved variable naming fromaccounttotx.Renaming the variable from
accounttotximproves semantic clarity since the variable represents a transaction object, not just an account.Also applies to: 18-18
32-32: Good practice usingundefinedassignment instead ofdeleteoperator.Using
tx.RegularKey = undefinedrather than thedeleteoperator is a better practice for performance, as recommended by static analysis tools.
28-28: Streamlined test assertions with helper functions.Replacing direct assertion calls with the helper functions makes the tests more concise and readable while maintaining the same validation logic.
Also applies to: 33-33, 39-39
packages/xrpl/test/models/clawback.test.ts (2)
1-6: Improved test organization with helper functions.The introduction of utility functions and local wrapper functions creates a more maintainable and consistent approach to validation testing across the codebase.
25-25: Streamlined test assertions with helper functions.Replacing direct assertion calls with the helper functions makes the tests more concise and readable while maintaining the same validation logic and expected error messages.
Also applies to: 34-34, 44-44, 52-52, 66-66, 80-80, 94-94, 107-107, 122-122
packages/xrpl/test/models/offerCancel.test.ts (4)
2-6: Improved test structure with utility functionsThe refactored code now uses centralized utility functions for validation, making the tests more concise and maintainable. Good addition of helper functions
assertValidandassertInvalidto encapsulate the validation logic.
14-14: Type annotation adds clarityExplicitly typing
offerasanyimproves code clarity and prevents potential type-related issues.
33-33: Streamlined validation assertionReplacing the direct validation call with the wrapper function
assertValidmakes the code more readable and consistent with other tests.
42-43: Better test case and improved error validationChanged from numeric string '99' to 'abcd' for invalid OfferSequence, which is a more obvious non-numeric value. The validation error handling is now more consistent with the use of
assertInvalid.packages/xrpl/test/models/NFTokenCreateOffer.test.ts (3)
1-8: Well-structured helper functionsGood implementation of utility functions with clear parameter typing. The helper functions make the test assertions more concise while maintaining proper validation.
32-32: Simplified valid transaction testingUsing
assertValidinstead of direct validation calls makes the code cleaner and easier to maintain.
81-84: Improved error validation readabilityThe refactored code places the transaction object and error message on separate lines, improving readability while maintaining the same validation logic.
packages/xrpl/test/models/AMMClawback.test.ts (2)
5-9: Good use of utility functionsThe implementation of utility functions with proper type annotation improves code readability and maintainability.
17-17: Explicit type annotation adds clarityProperly typing
ammClawbackasanyimproves code clarity.packages/xrpl/test/models/permissionedDomainSet.test.ts (3)
3-10: Well-structured utility functionsGood implementation of helper functions with proper type annotations. The imports and utility functions are well-organized.
18-18: Explicit typing improves clarityProperly typing
txasanyadds clarity to the code.
37-37: Simplified validation assertionUsing
assertValidmakes the code more concise while maintaining the same validation logic.packages/xrpl/test/models/NFTokenMint.test.ts (6)
1-9: Improved test utilities implementation.The changes introduce better structured imports and helper functions for validation assertions. The switch to
stringToHexfrom the isomorphic package standardizes string conversion across the codebase, and the local helper functions make test assertions more readable and consistent.
29-32: Well-structured test validation.Replacing direct assertions with the helper function improves readability and maintainability. The validation now checks both the specific
validateNFTokenMintfunction and the genericvalidatefunction.
48-49: Standardized validation approach.The helper function provides a consistent way to validate the transaction without repetitive code, ensuring both the specific and generic validators are checked.
60-61: Consistent error assertion pattern.Using the helper function for validation error checks improves consistency across all test cases while maintaining the same validation logic and error messages.
Also applies to: 63-64
76-77: Streamlined validation error checking.The helper function simplifies error validation while ensuring both the specific validator and generic validator throw the expected error.
Also applies to: 79-80
95-96: Uniform validation error handling across all test cases.All error validation cases now follow the same pattern, making the test suite more maintainable while preserving the validation rules and error messages.
Also applies to: 111-112, 125-127, 142-144
packages/xrpl/test/models/MPTokenIssuanceSet.test.ts (3)
1-8: Improved test structure with specialized helpers.The changes introduce focused imports and helper functions that streamline validation in the test cases. This approach reduces duplication and promotes consistency across test files.
26-27: Consistent validation pattern for all test cases.All validation cases now use the same helper function, ensuring both the specific validator and generic validator are checked consistently. This maintains the validation logic while improving code clarity.
Also applies to: 36-37, 46-47
55-58: Standardized error validation approach.Error cases now follow a consistent pattern with the helper function, ensuring proper validation error checking while maintaining the same test coverage.
Also applies to: 72-73, 76-77
packages/xrpl/test/testUtils.ts (3)
8-13: Enhanced imports for validation utilities.Adding
validateandValidationErrorto the imports provides the necessary components for the new utility functions. This centralizes validation logic for all transaction tests.
60-69: Well-designed validation success utility.The
assertTxIsValidfunction provides a standardized way to assert that a transaction passes both the specific validator and the generic validator. This eliminates duplicate assertion code across test files.
71-85: Robust validation error utility.The
assertTxValidationErrorfunction ensures that both the specific validator and the generic validator throw the expected error with the correct message. This provides consistent error checking across all transaction tests.packages/xrpl/test/models/MPTokenIssuanceCreate.test.ts (3)
1-10: Improved test structure with standardized helpers.The import of
stringToHexfrom the isomorphic package ensures consistent string conversion. The helper functions provide a clean interface for validation assertions throughout the test file.
27-28: Standardized string encoding and validation assertion.Using the standardized
stringToHexfunction and the helper validation function improves consistency and readability while maintaining the same test coverage.Also applies to: 30-31
41-44: Consistent error validation across all test cases.All error validation tests now follow the same pattern using the helper function, ensuring both validators are checked with the expected error messages. This maintains test coverage while improving code maintainability.
Also applies to: 55-58, 68-69, 76-77, 84-85, 94-97, 105-108, 116-119, 128-131
packages/xrpl/HISTORY.md (1)
14-14: Clear documentation of bug fix.The changelog entry accurately documents the bug fix for transactions that would crash during validation, which aligns with the code changes in MPTokenIssuanceCreate.ts and MPTokenIssuanceSet.ts files.
packages/xrpl/src/models/transactions/MPTokenIssuanceCreate.ts (1)
160-162: Good defensive coding with nullish coalescing operator.Using
?? 0to defaulttx.Flagsto zero when it's undefined or null prevents potential crashes during validation. This is a good defensive programming practice that handles edge cases gracefully.packages/xrpl/src/models/transactions/MPTokenIssuanceSet.ts (1)
72-72: Good defensive coding with nullish coalescing operator.Using
?? 0to defaulttx.Flagsto zero when it's undefined or null prevents potential crashes during validation. This is consistent with similar changes in MPTokenIssuanceCreate.ts.
| @@ -69,7 +69,7 @@ export function validateMPTokenIssuanceSet(tx: Record<string, unknown>): void { | |||
| validateOptionalField(tx, 'Holder', isAccount) | |||
|
|
|||
| // eslint-disable-next-line @typescript-eslint/consistent-type-assertions -- Not necessary | |||
| const flags = tx.Flags as number | MPTokenIssuanceSetFlagsInterface | |||
| const flags = (tx.Flags ?? 0) as number | MPTokenIssuanceSetFlagsInterface | |||
There was a problem hiding this comment.
why is the default needed here?
There was a problem hiding this comment.
The ternary below breaks otherwise. Not really sure what changed in this PR such that it didn't break before, tbh - maybe just more consistent testing/that's set somewhere else?
| const assertValid = (tx: any): void => | ||
| assertTxIsValid(tx, validateCredentialAccept) | ||
| const assertInvalid = (tx: any, message: string): void => | ||
| assertTxValidationError(tx, validateCredentialAccept, message) |
There was a problem hiding this comment.
continuing off of the thread in the other PR, I like the new assertTxIsValid methods, but I'm not sure about aliasing it here again as assertInvalid, since it seems to not simplify anything besides the function name
There was a problem hiding this comment.
It passes in the validate[TxType] function as a parameter, so that you don't have to pass it in every time you run it. This makes tests a little cleaner - a basic assertValid and assertInvalid.
High Level Overview of Change
This PR refactors the transaction model tests to be more consistent via a couple of helper functions, and fixes a couple of minor bugs along the way.
While the diff is rather large, most of the changes are fairly systematic.
Context of Change
Pulled out of #2895 to make that PR simpler
Type of Change
Did you update HISTORY.md?
Test Plan
CI passes.