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

test setup #74 #75

Closed

Conversation

AhmedEldessouki
Copy link
Contributor

No description provided.

@AhmedEldessouki
Copy link
Contributor Author

resolves #74

 removed The AllRaid assertions from App.test and moved them to AllRaids.test.
wrote ViewRaid Tests to cover all sorting the the Total view
Copy link
Contributor

@nobrayner nobrayner left a comment

Choose a reason for hiding this comment

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

Some general things:

  • I don't like all the mocking, but I am unsure how to avoid it at this point
  • I would prefer component/route tests to be collocated

package.json Outdated Show resolved Hide resolved
src/__tests__/AllRaids.test.tsx Show resolved Hide resolved
src/__tests__/App.test.tsx Outdated Show resolved Hide resolved
src/__tests__/Raids.test.tsx Outdated Show resolved Hide resolved
src/__tests__/Raids.test.tsx Show resolved Hide resolved
src/__tests__/Raids.test.tsx Outdated Show resolved Hide resolved
src/__tests__/Raids.test.tsx Outdated Show resolved Hide resolved
src/tests/data/raidsData.ts Show resolved Hide resolved
src/tests/data/raidsData.ts Show resolved Hide resolved
@nobrayner nobrayner linked an issue Feb 1, 2021 that may be closed by this pull request
@nobrayner nobrayner added the Status: Revision Needed 💭 Was your sword bent or shield cracked!? It's ok we got you, we defeat or are defeated AS ONE!!! label Feb 1, 2021
package.json Show resolved Hide resolved
src/__tests__/firestore.ts Outdated Show resolved Hide resolved
@nobrayner
Copy link
Contributor

Thanks for working on this - you are doing some great work 🎊

@AhmedEldessouki
Copy link
Contributor Author

Thanks for working on this - you are doing some great work 🎊

Thanks 🙂

@JacobMGEvans JacobMGEvans added Status: In Progress 🚧 Currently taking out the trash mobs or cleaning up the dungeon Type: Test Your Mettle 🧪 Can your code hold up to the brutal crucible of tests!? labels Feb 3, 2021
package.json Outdated
"test": "jest --watch --FIRESTORE_EMULATOR_HOST=8080",
"test:ci": "jest",
"test": "jest --watch",
"test:ci": "jest --findRelatedTests",
Copy link
Contributor Author

@AhmedEldessouki AhmedEldessouki Feb 5, 2021

Choose a reason for hiding this comment

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

--findRelatedTests forces jest from running cypress's tests (lint-stage for some reason forces jest to run cypresses tests)🙂

@JacobMGEvans JacobMGEvans added the CTA: Help Wanted CALL TO ACTION: Rally to Aid a fellow Raid Member!!! label Feb 5, 2021
@nobrayner
Copy link
Contributor

So just some reminders for myself, and to mention a few things:

I don't like all the mocking, but I am unsure how to avoid it at this point

This can be fixed by making the test command use firebase emulators:exec --only firestore "jest --watch" for example. This will start up the firestore emulator, run jest (with full watch mode stuff working), then when you quit jest, the emulators cleanly shutdown. This then allows us to avoid mocking completely.

You can see how I got this working in Guild Scrivener:
https://github.com/OpenSourceRaidGuild/Guild-Scrivener/blob/main/package.json
https://github.com/OpenSourceRaidGuild/Guild-Scrivener/tree/main/src/testUtils
https://github.com/OpenSourceRaidGuild/Guild-Scrivener/blob/main/src/setupTests.ts

  • I would prefer component/route tests to be collocated

Looks like the tests are still hanging out under the __tests__. Honestly, the original intention was to have a tests folder per place that needed testing.... But that seems overly complicated now, and should probably just be the test files sitting right next to the things they test.

@AhmedEldessouki
Copy link
Contributor Author

This can be fixed by making the test command use firebase emulators:exec --only firestore "jest --watch" for example. This will start up the firestore emulator, run jest (with full watch mode stuff working), then when you quit jest, the emulators cleanly shutdown. This then allows us to avoid mocking completely.

But isn't the way you started the emulators wouldn't import the dev-data file. Are intending you fully create a collection before running a test?

You can see how I got this working in Guild Scrivener:
https://github.com/OpenSourceRaidGuild/Guild-Scrivener/blob/main/package.json
😍 pretty smart i must say. why doesn't it work if you ran it like this "run-s exec:firestore test" 🤓

https://github.com/OpenSourceRaidGuild/Guild-Scrivener/tree/main/src/testUtils
🤯🤯 no idea whats going on except for most of faker usage

https://github.com/OpenSourceRaidGuild/Guild-Scrivener/blob/main/src/setupTests.ts
when i started testing my app (which is also) using firebase. I used to get my API like this [...API_KEY]. so how did dotenv.config(); fix it? ... i used to think that Kent did something so people like me wouldn't do the mistake of testing using the same backend the app uses.

  • I would prefer component/route tests to be collocated
    +1
    @JacobMGEvans what do you think? ⬆⬆

Looks like the tests are still hanging out under the __tests__. Honestly, the original intention was to have a tests folder per place that needed testing.... But that seems overly complicated now, and should probably just be the test files sitting right next to the things they test.
are you thinking components/__tests__ or components/{whatever}/__tests__ ? 🤔

Copy link
Contributor

@nobrayner nobrayner left a comment

Choose a reason for hiding this comment

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

@AhmedEldessouki I'll answer some of your questions below 😄

why doesn't it work if you ran it like this run-s exec:firestore test

If you meant start:firestore - yes, that would work. But why should I bother about adding in another dependency, when the firebase emulator supports the usecase we have out of the box? Sorry, this would NOT work. run-s runs things sequentially, and the firestore emulator just runs until stopped - so it would never run the test script.

🤯🤯 no idea whats going on except for most of faker usage

Ask any questions in Discord, and I'll do my best to explain!

are you thinking components/tests or components/{whatever}/tests ? thinking

Neither, actually. That's what I was originally thinking. Now I believe doing something like components/loadingScreen/loadingScreen.test.ts <-- this will place it right next to the file it is testing.

"start:dev": "snowpack dev",
"start:firestore": "firebase emulators:start --import=./devData --only firestore",
"build": "snowpack build",
"test": "jest --watch",
"test": "jest --watch --FIRESTORE_EMULATOR_HOST=8080",
Copy link
Contributor

Choose a reason for hiding this comment

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

when i started testing my app (which is also) using firebase. I used to get my API like this [...API_KEY]. so how did dotenv.config(); fix it? ... i used to think that Kent did something so people like me wouldn't do the mistake of testing using the same backend the app uses.

Dotenv just imported whatever I had in my .env file, as without those, it would fall over. This also meant that I don't have to worry about var being added or removed. It becomes extremely(!!!!) important to make sure you aren't "leaking" anything out to the real world, however. In Scrivener, I am managing this by using MSW with a catchall:

  rest.get('*', (req, res, ctx) => {
    const warning = `${req.url} has not been mocked yet... Maybe now is a good time to do that`;
    console.warn(warning);
    return res(ctx.json(warning));
  }),

And then firestore has this really nice feature of the FIRESTORE_EMULATOR_HOST env var, which will make it point to the emulator instead of real firebase.

Copy link
Contributor Author

@AhmedEldessouki AhmedEldessouki Feb 11, 2021

Choose a reason for hiding this comment

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

Sorry, this would NOT work. run-s runs things sequentially, and the firestore emulator just runs until stopped - so it would never run the test script.

I thought it will run firestore emulator then jest. but even run-p didn't work even thu it worked with start command.

components/loadingScreen/loadingScreen.test.ts <-- this will place it right next to the file it is testing.

this will surely be a lot cleaner. I will do the changes.
@JacobMGEvans is it okay to do so?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i see now. that cleared alot of things for me. 🙏🏼 thanks 🙂
using the emulator is way better than using MSW to fake the requests. because firebase url are pretty damn big.

Suggested change
"test": "jest --watch --FIRESTORE_EMULATOR_HOST=8080",
"test": "jest --watch",

I dont think that the FIRESTORE_EMULATOR_HOST var works here in this line. when i added it, it was for the test env to pick up on it but the way you wrote the script and configured the env var bypassed its use case.

Copy link
Contributor

Choose a reason for hiding this comment

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

@AhmedEldessouki the way you set it here doesn't set an env var. You will have to use something like cross-env and set it first - see Guild Scrivener for how I setup a generic "execute firestore" command that everything else hooks off of for a solid example.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks for pointing that out 🙂 I will look for it 😁😁

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cant work around this. int the Guild Scrivener you are using Node env. do you think it's possible for @firebase/testing to work in Jsdom env?
Error: FIRESTORE (8.2.4) INTERNAL ASSERTION FAILED: Unexpected state

I ran into this problem before when i was testing firestore-rules (Node env). after i worked around it, jsdom tests was being unexpected and then i removed firestore-rules test

Comment on lines +18 to +24
jest.doMock('../utils/useDocument', () =>
jest.fn().mockReturnValue(fetchedDocumentData),
)
jest.doMock('../utils/useCollection', () =>
jest.fn().mockReturnValue(fetchedCollectionData),
)
jest.spyOn(console, 'log')
Copy link
Contributor

Choose a reason for hiding this comment

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

When we use the emulators, we don't have to mock anything because we are just interfacing with the emulator instead of the real thing - yes you still have to "seed" the data.

This can be done by just importing from the devData dir for now, as the website is really read-only.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When we use the emulators, we don't have to mock anything

totally agree. i tried it before mocking but when it failed i when with mocking. i will do remove the mocks.

Comment on lines +21 to +26
// console.log({
// name: name.value,
// raidName: raidName.value,
// rate: rate.value,
// description: description.value,
// })
Copy link
Member

Choose a reason for hiding this comment

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

Clean up later

)
}

export * from '@testing-library/react'
Copy link
Member

Choose a reason for hiding this comment

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

Why is this being exported?

Copy link
Contributor

@nobrayner nobrayner Feb 11, 2021

Choose a reason for hiding this comment

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

I believe it is so there is a single import { xyz } from '../path/to/testUtils' instead of importing things from '@testing-library/react' itself AND 'testUtils'.

@JacobMGEvans JacobMGEvans mentioned this pull request Feb 13, 2021
@JacobMGEvans
Copy link
Member

Replaced By #83

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CTA: Help Wanted CALL TO ACTION: Rally to Aid a fellow Raid Member!!! Status: In Progress 🚧 Currently taking out the trash mobs or cleaning up the dungeon Status: Pending ⏳ Status: Revision Needed 💭 Was your sword bent or shield cracked!? It's ok we got you, we defeat or are defeated AS ONE!!! Type: Test Your Mettle 🧪 Can your code hold up to the brutal crucible of tests!?
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Tests
3 participants