Skip to content
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

initializeTestApp from @firebase/rules-unit-testing with jest, file scope variables are unset #3920

Closed
ScottPierce opened this issue Oct 10, 2020 · 4 comments · Fixed by #3923
Assignees
Labels
api: firestore testing-sdk testing with emulator

Comments

@ScottPierce
Copy link

ScottPierce commented Oct 10, 2020

[REQUIRED] Describe your environment

  • Operating System version: OSX
  • Browser version: This is for test
  • Firebase SDK version:
        "firebase": "^7.23.0",
        "firebase-admin": "^9.2.0",
        "@firebase/rules-unit-testing": "^1.0.7",
        "@firebase/testing": "^0.20.11",
  • Firebase Product: firestore
  • Running tests with Jest inside of a NX workspace library

[REQUIRED] Describe the problem

When I use initializeTestApp with the @firebase/rules-unit-testing, any variables that I set in the root scope of the file are invalidated in jest tests. The first test will pass, but then, when the second test is run, and initializeTestApp is called, the second test won't pass because file scoped variables are unset.

  • In the second test, if initializeTestApp is removed, the test passes just fine.
  • If the import is changed from @firebase/rules-unit-testing to @firebase/testing, the test passes just fine.

Likely Unrelated:
I'm doing this in an nx react application.

Steps to reproduce:

Run the given code sample with Jest. The second test will fail, even though it shouldn't, because testData.uid will be unset.

Again, simply changing the import from rules-unit-testing to testing fixes the problem.

Relevant Code:

import {
    apps,
    assertFails,
    assertSucceeds,
    clearFirestoreData,
    initializeAdminApp,
    initializeTestApp,
    loadFirestoreRules,
} from "@firebase/rules-unit-testing"

const testData = { uid: "UserId" }
const projectId = `user-feedback-db`
const myAuth = { uid: "user_me", email: "me@gmail.com" }

test("test1", () => {
    initializeTestApp({
        projectId: projectId,
        auth: myAuth
    })
    expect(testData.uid).toEqual("UserId")
})

test("test2", () => {
    initializeTestApp({
        projectId: projectId,
        auth: myAuth
    })
    expect(testData.uid).toEqual("UserId")
})
@n0mer
Copy link
Contributor

n0mer commented Oct 12, 2020

@ScottPierce i have the similar problem. Try downgrading @firebase/rules-unit-testing from 1.0.7 to 1.0.6, until this is fixed.

This serves as changelog: https://github.com/firebase/firebase-js-sdk/compare/@firebase/rules-unit-testing@1.0.6...@firebase/rules-unit-testing@1.0.7

@thebrianchen thebrianchen added the testing-sdk testing with emulator label Oct 12, 2020
@samtstern
Copy link
Contributor

samtstern commented Oct 12, 2020

@ScottPierce sorry about that this one is my fault, fixing it here:
#3923

In the meantime if you downgrade your rules-unit-testing dependency to 1.0.5 it should not have that bug.

@ScottPierce
Copy link
Author

ScottPierce commented Oct 12, 2020

How is this even possible? How did you unset variables in the parent scope, a const no less. I'm new to js / ts.

@samtstern
Copy link
Contributor

samtstern commented Oct 12, 2020

If you look at the PR you'll see I was doing delete auth.uid which removes the uid key from the object. I now make a copy before doing that.

const doesn't protect your obejct from being mutated, it only protects the reference from being reset. So:

const x = { a: 1 };

// This is allowed
x.a = 2;

// This is not allowed
x = { a: 2 };

@firebase firebase locked and limited conversation to collaborators Nov 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api: firestore testing-sdk testing with emulator
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants