-
Notifications
You must be signed in to change notification settings - Fork 624
Improve readability of a test in ApkUpdaterTest #4518
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
Conversation
Generated by 🚫 Danger |
Coverage Report 1Affected Products
Test Logs |
@@ -202,7 +202,7 @@ public void updateApk_whenSuccessfullyUpdated_notificationsSetCorrectly() | |||
|
|||
UpdateTask updateTask = apkUpdater.updateApk(TEST_RELEASE, true); | |||
List<UpdateProgress> events = | |||
awaitProgressEvents(updateTask, 3, mockConnectionLatch::countDown); | |||
awaitProgressEvents(updateTask, 3, countDownLatch::countDown); |
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.
I think this is difficult to understand. It might make sense to split up the awaitProgressEvents()
method to make this more readable. E.g.:
- declare the
progressEvents
lists here (inline) - add the listener here (inline)
- count down the latch here (inline)
- call the truncated helper function:
awaitProgressEvents(progressEvents, 3)
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.
Yes I like that a lot better, thanks!
Size Report 1Affected Products
Test Logs |
653c10a
to
75108e0
Compare
@@ -104,24 +105,15 @@ static void awaitAsyncOperations(ExecutorService executorService) throws Interru | |||
/** Await a specified number of progress events on an {@link UpdateTask}. */ | |||
static List<UpdateProgress> awaitProgressEvents(UpdateTask updateTask, int count) |
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.
Aren't all callers of this prone to the problem that the task might have completed before the listener is added?
I think it might make sense to inline this everywhere (and employ a latch to prevent the race)
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.
Yeah I think you're right. There's only one other usage and maybe we're just getting lucky that it hasn't been failing. Updated.
Startup Time Report 1Note: Layout is sometimes suboptimal due to limited formatting support on GitHub. Please check this report on GCS. Startup time comparison between the CI merge commit (6a1fa5f) and the base commit (8c83cfc) are not available. No macrobenchmark data found for the base commit (8c83cfc). Analysis for the CI merge commit (6a1fa5f) can be found at: |
/** Await a specified number of progress events on an {@link UpdateTask}. */ | ||
static List<UpdateProgress> awaitProgressEvents(UpdateTask updateTask, int count) | ||
/** Await a specified number of progress events being added to the given collection. */ | ||
static void awaitProgressEvents(Collection<UpdateProgress> progressEvents, int count) |
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.
Sorry, but I keep having ideas for this:
I think generalizing this would actually make it more readable. It doesn't need to be full-featured like http://google3/java/com/google/testing/util/WaitForCondition.java
How about:
static void waitForCondition(BooleanSupplier condition) {
ExecutorService executor = TestOnlyExecutors.blocking();
executor.execute(
() -> {
while (!condition.getAsBoolean()) {
try {
Thread.sleep(50);
} catch (InterruptedException e) {
throw new RuntimeException("Interrupted while waiting for progress events", e);
}
}
});
executor.awaitTermination(500, TimeUnit.MILLISECONDS);
assertThat(condition.getAsBoolean());
}
That way the caller becomes more expressive:
waitForCondition(() -> progressEvents.size() == 3);
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.
No I think this makes more sense now that most of the progress event specific logic is gone. I also removed the Executor since I realized that wasn't actually adding value. It was also inadvertently causing us to wait a minimum of 500ms each time.
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.
Sorry 'bout all the bikeshedding
bef927c
to
385d2cc
Compare
* Rename CountDownLatch and inline more of the setup to improve readability. * Use a latch for the other usage of awaitProgressEvents() * Refactor awaitProgressEvents into awaitCondition
* Rename CountDownLatch and inline more of the setup to improve readability. * Use a latch for the other usage of awaitProgressEvents() * Refactor awaitProgressEvents into awaitCondition
* Rename CountDownLatch and inline more of the setup to improve readability. * Use a latch for the other usage of awaitProgressEvents() * Refactor awaitProgressEvents into awaitCondition
* Rename CountDownLatch and inline more of the setup to improve readability. * Use a latch for the other usage of awaitProgressEvents() * Refactor awaitProgressEvents into awaitCondition
Uh oh!
There was an error while loading. Please reload this page.