Add README.md about spec tests

[dconeybe]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: be560ab

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[google-oss-bot]

Binary Size Report

Affected SDKs

• @firebase/database-exp

  Type	Base (21ee150)	Head (cbe0ea5)	Diff
  browser	277 kB	277 kB	-59 B (-0.0%)
  esm2017	241 kB	241 kB	-59 B (-0.0%)
  main	279 kB	279 kB	-158 B (-0.1%)
  module	277 kB	277 kB	-59 B (-0.0%)

Test Logs

• Base (21ee150c): https://github.com/firebase/firebase-js-sdk/actions/runs/541229347
• Head (cbe0ea5c): https://github.com/firebase/firebase-js-sdk/actions/runs/548475955

[google-oss-bot]

Size Analysis Report

Affected Products

No changes between base commit (21ee150) and head commit (cbe0ea5).

Test Logs

• Base (21ee150): https://github.com/firebase/firebase-js-sdk/actions/runs/541229347
• Head (cbe0ea5): https://github.com/firebase/firebase-js-sdk/actions/runs/548475955

[schmidt-sebastian]

99% of JS developers now use VS Code. The other 1% works on Firestore. I think IntelliJ is not that good of a Web IDE unless users pay for the professional edition. I would state that the tests can be run via VS Code and IntelliJ, but mostly we should point out how to use the Node test runner.

I would also give a shout out to the fact that we fake IndexedDb persistence under Node.

[dconeybe]

I ended up just removing this paragraph about IntelliJ since the instructions for running the tests are documented in each repository and don't need to be duplicated here. I also mentioned the IndexedDb persistence faking above.

[schmidt-sebastian]

In general, this is a good starting point for a spec test introduction. I think the complications arise when someone wants to go past these setup steps, but I am honestly not quite sure how we could teach someone how to write a spec test over a README. The actual tests require an insane amount of technical knowledge, and I would be wary to put all this in writing.

Even if we want to focus on the high level nature of these tests, we may still want to expand on this and write about the tags. We should mention "exclusive", "no-ios" and "no-android" (and maybe "no-web", but I don't know when that would make sense).

[dconeybe]

That's a good point about the tags. I've added information about the tags. I agree that trying to document the spec tests in their entirety is not feasible. I am mostly writing this so that the next time I need to work on the spec tests I have something to remind me of the basics, and this will hopefully be helpful to future authors as well.

[schmidt-sebastian]

Thanks!