-
Notifications
You must be signed in to change notification settings - Fork 427
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
Add Assertion to the SharedTimerTest
#2381
Add Assertion to the SharedTimerTest
#2381
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2381 +/- ##
============================================
+ Coverage 50.03% 50.21% +0.18%
- Complexity 3785 3842 +57
============================================
Files 143 145 +2
Lines 33204 33360 +156
Branches 5629 5654 +25
============================================
+ Hits 16613 16752 +139
- Misses 14207 14210 +3
- Partials 2384 2398 +14 ☔ View full report in Codecov by Sentry. |
src/test/java/com/microsoft/sqlserver/jdbc/SharedTimerTest.java
Outdated
Show resolved
Hide resolved
src/test/java/com/microsoft/sqlserver/jdbc/SharedTimerTest.java
Outdated
Show resolved
Hide resolved
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.
please update as per review comments
Resolve #2357
Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it
When I am walking through the unit test of the mssql-jdbc, I noticed that currently the
SharedTimerTest
does not contain any assertion statement to verify the behavior and state of theSharedTimer
after execution of itsgetTimer()
method in a multithreaded environment. The test ensures that references are added and removed, but does not assert the expected state of the SharedTimer (e.g., it is stopped and cleaned up properly after all references are removed). This could potentially mask issues with howSharedTimer
manages its lifecycle and resources.Current Implementation:
Describe the preferred solution
I'd like to propose a minor improvement by adding a simple assertion at the end of the getTimer test method to verify that the SharedTimer has indeed been stopped and its resources have been cleaned up after all references to it have been removed. This could be accomplished by asserting that SharedTimer.isRunning() returns false, indicating that the internal ScheduledThreadPoolExecutor has been shut down and the SharedTimer instance has been cleaned up. Here is the suggested code snippet for this improvement:
Describe alternatives you've considered
An alternative would be to incorporate more detailed logging within the SharedTimer class regarding its state transitions (e.g., when references are added or removed, and when it starts or stops). While this would provide more insight during test execution, it would not replace the need for explicit assertions to verify the correct behavior programmatically.
Reference Documentations/Specifications
This suggestion does not directly relate to any specific JDBC Specifications.