-
Notifications
You must be signed in to change notification settings - Fork 32
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
refactor unit tests on package lock #374
Conversation
creativeprojects
commented
Jun 28, 2024
•
edited
Loading
edited
- refactoring of unit tests on the package lock
- commit generated mocks with a more recent version of mockery
- remove obsolete golangci-lint configuration
a ping to localhost doesn't necessarily work on some firewalled computers
WalkthroughThe overall changes primarily involve minor version updates to code generation tools and significant refactoring of test functions for improved readability and structure. Specifically, the code generation tool Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
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 as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (7)
- config/mocks/NamedPropertySet.go (1 hunks)
- config/mocks/ProfileInfo.go (1 hunks)
- config/mocks/PropertyInfo.go (1 hunks)
- config/mocks/SectionInfo.go (1 hunks)
- lock/lock_test.go (14 hunks)
- monitor/mocks/OutputAnalysis.go (1 hunks)
- schedule/mocks/Handler.go (1 hunks)
Files skipped from review due to trivial changes (6)
- config/mocks/NamedPropertySet.go
- config/mocks/ProfileInfo.go
- config/mocks/PropertyInfo.go
- config/mocks/SectionInfo.go
- monitor/mocks/OutputAnalysis.go
- schedule/mocks/Handler.go
Additional context used
golangci-lint
lock/lock_test.go
285-285: 285-309 lines are duplicate of
lock/lock_test.go:311-335
(dupl)
311-311: 311-335 lines are duplicate of
lock/lock_test.go:285-309
(dupl)
Additional comments not posted (6)
lock/lock_test.go (6)
34-39
: Well-implemented helper function for temporary files.The
getTempfile
function correctly utilisest.TempDir()
and logs the temporary file used, which enhances test traceability.
42-45
: Refactoring to use helper functiongetTempfile
is correctly implemented.Using
getTempfile
ensures consistency in how temporary files are handled across tests.
74-76
: Good use ofgetTempfile
and correct error handling testing.The test correctly handles scenarios where no PID is set, which is crucial for robustness.
90-92
: Correct implementation of PID setting in tests.The test ensures that the PID is set correctly and verifies it, which is essential for ensuring the lock's functionality.
107-109
: Proper handling of multiple PID settings in tests.This test effectively checks the behaviour when multiple PIDs are set, which is crucial for complex scenarios.
126-127
: Effective testing of process completion.The test correctly determines if a child process has finished, which is vital for process management.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- lock/lock_test.go (15 hunks)
Additional context used
golangci-lint
lock/lock_test.go
26-26: don't use
init
function(gochecknoinits)
[medium] 320-320: G204: Subprocess launched with a potential tainted input or cmd arguments
(gosec)
Additional comments not posted (16)
lock/lock_test.go (16)
15-15
: Review of imports and global variable declarationThe imports added are necessary for the new functionalities introduced in the test file. Changing
helperBinary
from a constant to a variable is appropriate given the platform-dependent modification in theinit
function.Also applies to: 22-22
36-42
: Review ofgetTempfile
functionThe implementation of
getTempfile
is clear and effective, providing a reusable way to generate temporary files for tests, which enhances test isolation and cleanliness.
44-53
: Review ofTestLockIsAvailable
functionThe test is well-structured, making good use of parallel execution and the
getTempfile
helper. It correctly tests the lock acquisition functionality.
Line range hint
55-71
: Review ofTestLockIsNotAvailable
functionThis test is correctly designed to check the lock's behaviour when it is already acquired. It effectively uses assertions to validate the lock status and the identity of the lock holder.
Tools
golangci-lint
26-26: don't use
init
function(gochecknoinits)
Line range hint
76-88
: Review ofTestNoPID
functionThe test effectively simulates and validates the scenario where no PID is associated with the lock. It uses the
getTempfile
helper for setup and correctly asserts the expected outcomes.
Line range hint
92-104
: Review ofTestSetOnePID
functionThe test is well-structured, setting a PID and verifying it through subsequent calls. It makes effective use of the
getTempfile
helper and parallel execution.
Line range hint
109-123
: Review ofTestSetMorePID
functionThis test correctly simulates setting multiple PIDs in sequence and validates that the last set PID is the one that is retrieved, demonstrating the lock's behaviour in handling multiple PIDs.
Line range hint
128-150
: Review ofTestProcessFinished
functionThe test effectively uses a signalled command to simulate a process scenario. It sets a PID, runs the command, and correctly asserts whether the process still exists, providing a clear validation of the process's end state.
Line range hint
152-175
: Review ofTestProcessNotFinished
functionThis test effectively simulates a scenario where a process is expected to be running. It uses the
helperBinary
to ensure the process runs for a sufficient duration and correctly asserts the process's state.
181-189
: Review ofTestForceLockIsAvailable
functionThis test is correctly structured to validate the functionality of forcefully acquiring a lock, using the
getTempfile
helper for setup and asserting the expected behaviour.
Line range hint
191-205
: Review ofTestForceLockWithNoPID
functionThis test effectively simulates and validates the scenario where a force lock is attempted without any PID being set. It uses the
getTempfile
helper for setup and correctly asserts the expected outcomes.
Line range hint
207-229
: Review ofTestForceLockWithExpiredPID
functionThis test effectively simulates and validates the scenario where a force lock is attempted with an expired PID. It uses the
getTempfile
helper for setup and correctly asserts the expected outcomes, including the manual closure of the lockfile handle.
Line range hint
237-265
: Review ofTestForceLockWithRunningPID
functionThis test effectively simulates and validates the scenario where a force lock is attempted with a running PID. It uses the
helperBinary
to ensure the process runs for a sufficient duration and correctly asserts the lock's behaviour in this situation.
Line range hint
266-279
: Review ofTestLockWithNoInterruption
functionThis test effectively simulates and validates the scenario where a lock is acquired and released without any interruptions. It uses the
helperBinary
to ensure the process runs smoothly and correctly asserts the expected outcomes.
Line range hint
285-305
: Review ofTestLockIsRemovedAfterInterruptSignal
functionThis test effectively simulates and validates the scenario where a lock is acquired and then removed after receiving an interrupt signal. It uses the
helperBinary
to ensure the process is interrupted correctly and asserts the expected outcomes.
Line range hint
311-333
: Review ofTestLockIsRemovedAfterInterruptSignalInsideShell
functionThis test effectively simulates and validates the scenario where a lock is acquired and then removed after receiving an interrupt signal inside a shell command. It uses the
helperBinary
to ensure the process is interrupted correctly and asserts the expected outcomes.Tools
golangci-lint
[medium] 320-320: G204: Subprocess launched with a potential tainted input or cmd arguments
(gosec)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- lock/lock_test.go (13 hunks)
Files skipped from review as they are similar to previous changes (1)
- lock/lock_test.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- lock/lock_test.go (13 hunks)
Files skipped from review as they are similar to previous changes (1)
- lock/lock_test.go