Skip to content

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

Merged
merged 3 commits into from
Jan 4, 2023

Conversation

lfkellogg
Copy link
Contributor

@lfkellogg lfkellogg commented Jan 4, 2023

  • The latch's name made it seem like it was a mock
  • Inlining more of the setup makes it more readable

@google-oss-bot
Copy link
Contributor

1 Warning
⚠️ Did you forget to add a changelog entry? (Add the 'no-changelog' label to the PR to silence this warning.)

Generated by 🚫 Danger

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Jan 4, 2023

Coverage Report 1

Affected Products

  • firebase-appdistribution

    Overall coverage changed from ? (8c83cfc) to 77.39% (6a1fa5f) by ?.

    44 individual files with coverage change

    FilenameBase (8c83cfc)Merge (6a1fa5f)Diff
    AabUpdater.java?98.67%?
    ApkInstaller.java?100.00%?
    ApkUpdater.java?93.07%?
    AppDistributionReleaseImpl.java?100.00%?
    AppDistributionReleaseInternal.java?100.00%?
    AppIconSource.java?84.62%?
    AutoValue_AppDistributionReleaseImpl.java?65.45%?
    AutoValue_AppDistributionReleaseInternal.java?71.58%?
    AutoValue_ImageUtils_ImageSize.java?35.00%?
    AutoValue_TesterApiDisabledErrorDetails.java?29.41%?
    AutoValue_TesterApiDisabledErrorDetails_HelpLink.java?54.17%?
    AutoValue_UpdateProgressImpl.java?65.96%?
    ErrorMessages.java?0.00%?
    FeedbackActivity.java?1.12%?
    FeedbackSender.java?84.62%?
    FirebaseAppDistributionExceptions.java?80.00%?
    FirebaseAppDistributionFileProvider.java?0.00%?
    FirebaseAppDistributionImpl.java?89.89%?
    FirebaseAppDistributionLifecycleNotifier.java?92.91%?
    FirebaseAppDistributionNotificationsManager.java?87.18%?
    FirebaseAppDistributionRegistrar.java?86.27%?
    FirebaseAppDistributionTesterApiClient.java?88.54%?
    HttpsUrlConnectionFactory.java?50.00%?
    ImageUtils.java?100.00%?
    InstallActivity.java?2.67%?
    LogWrapper.java?100.00%?
    NewReleaseFetcher.java?85.11%?
    PackageInfoUtils.java?42.86%?
    ReleaseIdentifier.java?85.54%?
    ReleaseUtils.java?83.33%?
    ScreenshotTaker.java?41.18%?
    SequentialReference.java?100.00%?
    SignInResultActivity.java?0.00%?
    SignInStorage.java?100.00%?
    TakeScreenshotAndStartFeedbackActivity.java?0.00%?
    TaskCache.java?100.00%?
    TaskCompletionSourceCache.java?73.91%?
    TaskUtils.java?92.50%?
    TesterApiDisabledErrorDetails.java?93.75%?
    TesterApiHttpClient.java?90.18%?
    TesterSignInManager.java?96.12%?
    UpdateProgressImpl.java?100.00%?
    UpdateTaskCache.java?100.00%?
    UpdateTaskImpl.java?76.00%?

Test Logs

  1. https://storage.googleapis.com/firebase-sdk-metric-reports/Rbmnr7qZj2.html

@github-actions
Copy link
Contributor

github-actions bot commented Jan 4, 2023

Unit Test Results

166 tests   166 ✔️  43s ⏱️
  16 suites      0 💤
  16 files        0

Results for commit 385d2cc.

♻️ This comment has been updated with latest results.

@@ -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);
Copy link
Contributor

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)

Copy link
Contributor Author

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!

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Jan 4, 2023

Size Report 1

Affected Products

  • base

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    apk (aggressive)?8.39 kB? (?)
    apk (release)?8.65 kB? (?)
  • firebase-annotations

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    apk (aggressive)?8.39 kB? (?)
    apk (release)?9.46 kB? (?)
  • firebase-appdistribution

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?156 kB? (?)
    apk (aggressive)?833 kB? (?)
    apk (release)?2.01 MB? (?)
  • firebase-appdistribution-api

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?16.0 kB? (?)
    apk (aggressive)?95.8 kB? (?)
    apk (release)?706 kB? (?)
  • firebase-common

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?67.4 kB? (?)
    apk (aggressive)?95.1 kB? (?)
    apk (release)?700 kB? (?)
  • firebase-components

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?44.9 kB? (?)
    apk (aggressive)?8.68 kB? (?)
    apk (release)?33.6 kB? (?)
  • firebase-installations

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?55.0 kB? (?)
    apk (aggressive)?96.6 kB? (?)
    apk (release)?724 kB? (?)
  • firebase-installations-interop

    TypeBase (8c83cfc)Merge (6a1fa5f)Diff
    aar?8.05 kB? (?)
    apk (aggressive)?65.0 kB? (?)
    apk (release)?651 kB? (?)

Test Logs

  1. https://storage.googleapis.com/firebase-sdk-metric-reports/ezdlRHL0mC.html

@lfkellogg lfkellogg changed the title Rename CountDownLatch Improve readability of an test in ApkUpdaterTest Jan 4, 2023
@@ -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)
Copy link
Contributor

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)

Copy link
Contributor Author

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.

@lfkellogg lfkellogg changed the title Improve readability of an test in ApkUpdaterTest Improve readability of a test in ApkUpdaterTest Jan 4, 2023
@google-oss-bot
Copy link
Contributor

google-oss-bot commented Jan 4, 2023

Startup Time Report 1

Note: 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:

  1. https://storage.googleapis.com/firebase-sdk-metric-reports/JqcPZU3rxo/index.html

/** 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)
Copy link
Contributor

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);

Copy link
Contributor Author

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.

Copy link
Contributor

@kaibolay kaibolay left a 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

@lfkellogg lfkellogg merged commit 0df8309 into fad/in-app-feedback Jan 4, 2023
@lfkellogg lfkellogg deleted the lk/rename-latch branch January 4, 2023 19:39
lfkellogg added a commit that referenced this pull request Jan 5, 2023
* Rename CountDownLatch and inline more of the setup to improve readability.

* Use a latch for the other usage of awaitProgressEvents()

* Refactor awaitProgressEvents into awaitCondition
kaibolay pushed a commit that referenced this pull request Jan 23, 2023
* Rename CountDownLatch and inline more of the setup to improve readability.

* Use a latch for the other usage of awaitProgressEvents()

* Refactor awaitProgressEvents into awaitCondition
lfkellogg added a commit that referenced this pull request Jan 25, 2023
* Rename CountDownLatch and inline more of the setup to improve readability.

* Use a latch for the other usage of awaitProgressEvents()

* Refactor awaitProgressEvents into awaitCondition
lfkellogg added a commit that referenced this pull request Jan 25, 2023
* Rename CountDownLatch and inline more of the setup to improve readability.

* Use a latch for the other usage of awaitProgressEvents()

* Refactor awaitProgressEvents into awaitCondition
@firebase firebase locked and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants