## Description Many tests in the codebase are using `Thread.sleep()` with arbitrary wait times. This is a common anti-pattern that leads to: 1. **Flaky tests** - Tests may fail intermittently on slower machines or under heavy load 2. **Slow test execution** - Fixed sleep durations often wait longer than necessary 3. **Non-deterministic behavior** - Race conditions may still occur if the sleep duration is insufficient The project already has Awaitility as a dependency in multiple modules, making it straightforward to refactor these tests. ## Affected Files The following test files contain `Thread.sleep()` calls that should be reviewed and replaced: | File | Module | Usage Context | |------|--------|---------------| | `LeaderElectorTest.java` | kubernetes-client-api | Simulating renew deadline timeout (lines 73, 328, 330) | | `SerialExecutorTest.java` | kubernetes-client | Testing executor behavior with delays (lines 41, 68) | | `AbstractWatchManagerTest.java` | kubernetes-client | Waiting for reconnect scheduling (line 173) | | `UtilsTest.java` | kubernetes-client-api | Testing thread interruption handling (line 340) | | `WatchIT.java` | kubernetes-itests | Integration test with ping timeout (line 124) | ## Expected Behavior Tests should use one of the following approaches instead of `Thread.sleep()`: 1. **Awaitility** (preferred for most cases): ```java await().atMost(Duration.ofSeconds(5)) .untilAsserted(() -> assertEquals(expected, actual)); ``` 2. **CountDownLatch/CompletableFuture** for synchronization points: ```java CountDownLatch latch = new CountDownLatch(1); // ... trigger async operation that calls latch.countDown() assertTrue(latch.await(5, TimeUnit.SECONDS)); ``` ## Acceptance Criteria - [ ] All `Thread.sleep()` calls in test files are reviewed - [ ] Each usage is replaced with an appropriate deterministic alternative - [ ] Tests remain stable and pass consistently - [ ] No new flaky test failures are introduced - [ ] Test execution time is maintained or improved ## Additional Information Awaitility is already available as a dependency in the following modules: - `kubernetes-client-api` - `kubernetes-client` - `kubernetes-tests` - `kubernetes-itests` - `httpclient-*` modules - And others ## Tests After refactoring, run the full test suite multiple times to ensure stability: ```bash mvn test -pl kubernetes-client-api,kubernetes-client,kubernetes-itests -Dmaven.test.failure.ignore=false ```