Skip to content

Add priming logic to integration tests to avoid backend cold start issues. #1259

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 1 commit into from
Sep 28, 2018

Conversation

mikelehen
Copy link
Contributor

No description provided.

Copy link
Contributor

@wilhuff wilhuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does a before() block like this run before the entire test suite or before every test?

import { EventsAccumulator } from './util/events_accumulator';
import { withTestDoc } from './util/helpers';

// Firestore databases can be subject to a ~30s "cold start" delay if they have not been used
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line length?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Last week I added tslint enforcement of 100 (
    "max-line-length": [true, {"limit": 100, "ignore-pattern": "https?://"}],
    ), so I'm leaving this as is unless you care strongly about changing it.

@wilhuff wilhuff assigned mikelehen and unassigned wilhuff Sep 28, 2018
@mikelehen
Copy link
Contributor Author

Yeah, A before() block outside the context of a describe() will run before all tests in all suites.

@mikelehen mikelehen assigned wilhuff and unassigned mikelehen Sep 28, 2018
@wilhuff
Copy link
Contributor

wilhuff commented Sep 28, 2018

Doesn't this mean we start a listener and do a transaction for every test then? It seems like if all we care about is "priming" then we should be able to run this once.

Alternatively if test run times before and after are comparable then I guess it doesn't matter, but intuitively this seems like it could add up.

@mikelehen
Copy link
Contributor Author

Sorry, I was trying to describe when it runs, not how often... It'll only run once, regardless of how many tests are running.

Copy link
Contributor

@wilhuff wilhuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mikelehen mikelehen merged commit c577a7e into master Sep 28, 2018
@mikelehen mikelehen deleted the mikelehen/prime-backend branch September 28, 2018 19:38
mikelehen pushed a commit to firebase/firebase-ios-sdk that referenced this pull request Sep 28, 2018
…sues.

Port of firebase/firebase-js-sdk#1259 except I didn't use EventAccumulator
since it hits the default timeout. I just manually do the listener.
mikelehen added a commit to firebase/firebase-ios-sdk that referenced this pull request Oct 2, 2018
…sues. (#1890)

Port of firebase/firebase-js-sdk#1259 except I didn't use EventAccumulator
since it hits the default timeout. I just manually do the listener.
mikelehen added a commit to firebase/firebase-android-sdk that referenced this pull request Oct 3, 2018
…sues. (#50)

Port of firebase/firebase-js-sdk#1259 except reworked to use listener since EventAccumulator doesn't accept arbitrary timeouts.
@firebase firebase locked and limited conversation to collaborators Oct 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants