Add Parse Server + in-memory Mongo integration tests

[sadortun]

Summary

Adds an opt-in integration test suite that runs the Parse-backed and crypto code against a real Parse Server on an in-memory MongoDB (mongodb-memory-server). This complements the REST-mock unit tests (which verify our logic) by validating real query semantics, the findOrCreate mutex under concurrency, and — most importantly — the actual SecureObject/CryptoUtils encrypt→save→query→decrypt round-trip, which mocks can't exercise.

Stacked on cursor/fix-utils-bugs-and-tests-dc58 (PR #276). Retarget to master once that merges.

Design decisions

• Kept separate from yarn test. These tests pull in heavy dev-deps (parse-server, plus mongodb-memory-server which downloads a Mongo binary) and are slower, so they run via yarn test:integration with their own jest.integration.config.ts and *.itest.ts naming. The default unit run stays fast and CI-safe (unchanged at 145 tests).
• Server booted in globalSetup, not in a test file. parse-server.start() uses dynamic import(), which fails inside Jest's per-file VM (dynamic import callback was invoked without --experimental-vm-modules). globalSetup/globalTeardown run in Jest's main Node process where native dynamic import works; workers receive the URL/credentials via env vars.
• WebCrypto shim. The library reads window.crypto/window.performance; the setup exposes Node's WebCrypto + perf_hooks under window so SecureObject/CryptoUtils run unchanged.

What's covered (17 tests)

• Query: save + findBy, findOneBy, getObjectById (id / pointer / not-found), count, findAll, each, distinct, aggregate (server-side pipeline), findOrCreate (create + existing), a concurrency test proving the per-class mutex prevents duplicate creation, and CacheableQuery caching.
• SecureObject: secure fields are encrypted at rest (verified via a raw query — plaintext is absent) and transparently decrypted on read; saveAll; already-encrypted guard.
• CryptoUtils: PBKDF2 + encrypt/decrypt round-trip on real WebCrypto, random-IV uniqueness, and wrong-key failure.

Is more complete testing worth it?

Yes, for these modules specifically — they're security-critical and their real behavior (encryption, Mongo query semantics, concurrency) is exactly what unit mocks cannot prove. The cost is contained by making the suite opt-in. I would not push for broader integration coverage of the pure utility modules (ArrayUtils, StringUtils, etc.) — unit tests already cover those at 100% and a server adds no value there.

Validation

• yarn test:integration — 2 suites / 17 tests pass (~1s after server boot).
• yarn test (unit) — still 14 suites / 145 tests (integration files are not picked up).
• yarn build (tsc) — 0 errors. yarn lint — clean.

Notes

• parse-server writes a ./logs folder at startup regardless of silent; added /logs to .gitignore.
• CI must allow the one-time mongodb-memory-server binary download (or pre-provision MONGOMS_SYSTEM_BINARY).

  

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.