Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error handling in TestKeyAssignment #2337

Open
kirdatatjana opened this issue Oct 8, 2024 · 0 comments
Open

Improve error handling in TestKeyAssignment #2337

kirdatatjana opened this issue Oct 8, 2024 · 0 comments
Labels
status: waiting-triage This issue/PR has not yet been triaged by the team.

Comments

@kirdatatjana
Copy link
Contributor

kirdatatjana commented Oct 8, 2024

Problem

The integration test TestKeyAssignment in key_assignment.go has several test cases that use early returns on errors.
Since some test cases expect errors but don't check error types, this means that the tests would fail silently if errors are returned in places other than where the actual expected error is.

Problem details

The following test cases have early returns on errors, which can lead to false positive test results:

  • Double same-key assignment in the same block by different values
  • Double same-key assignment in the same block by the same value
  • Double same-key assignment in different blocks by different values

As a temporary solution, the test cases should panic in the event of an early error. These test cases need to be refactored to use proper error handling and ensure all checks are performed correctly.

An alternative solution could be to add checks for the exact error types or messages.

@kirdatatjana kirdatatjana added the status: waiting-triage This issue/PR has not yet been triaged by the team. label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-triage This issue/PR has not yet been triaged by the team.
Projects
Status: 🩹 F1: Triage
Development

No branches or pull requests

1 participant