#Testing Architecture

5 messages ยท Page 1 of 1 (latest)

rigid sail
#

Hey there ๐Ÿ‘‹

We're setting up an intentional (not coverage-driven) test suite for a Payload CMS app and trying to figure out the right infrastructure before writing any tests.

Our stack: Payload 3.x, MongoDB, Vitest

A few questions we're stuck on :

1. Test database isolation
What's the recommended approach : a dedicated MongoDB database (e.g. mongodb://127.0.0.1/myapp_test) pointed via env var, or mongodb-memory-server ?

We've seen Payload's own test suite uses a real DB, but is in-memory viable for app-level tests ? Any gotchas with the Mongoose adapter and in-memory DBs ?

2. DB lifecycle
Should the test DB be spun up once per test file (beforeAll) or reset between each test ?

We're currently leaning toward tracking created IDs and deleting them in afterEach rather than doing full collection drops, is that the pattern you'd recommend?

3. Seed strategy
For integration tests that need existing records (a user for auth, a product with relationships, etc.), do you use plain seed functions via the Local API, or do you maintain factories ? At what point does a factory pattern become worth the overhead ?

We couldn't find official Payload docs on testing for app developers (only the plugin dev guide touches on it briefly), so any community wisdom here would be hugely appreciated. ๐Ÿ™

dusky yacht
#

Hey @rigid sail are you specifically talking about a mobile Payload app? Just want to make sure I address this accurately!

rigid sail
rigid sail
#

but im just questioning on the tests architecture