goldbergyoni / goldbergyoni/nodejs-testing-best-practices
Best practices ideas
- Dominant language
- JavaScript
- Stars
- 4.4k
- Forks
- 288
- PR merge metrics
- No merged PRs in 30d
Description
Example here:
https://github.com/testjavascript/integration-tests-a-z/issues/43
YO, Two strategic topics:
1. Repo name and concept - Seems like we're going with the repo name: 'Integration Tests Best Practices', Any counter thoughts? Maybe 'Node.js Tests Best Practices' which makes it even more generic, opens the door for more topics but also less focused?
2. Best practices sketch - I'm including here a first draft of best practices idea and categorization (there will be more and each will include a longer explanation with code example), does this feel like the right taxonomy and will end in interesting content?
## The golden principles
Super simple, declarative and short (7 loc) tests
## Web server setup (3)
- Random port - Done
- Return the full address (maybe)
- Expose open and close methods - Done
- Mind remote environment (maybe)
- Same process - Done
## Infrastructure setup (6)
- Use docker-compose - Done
- In global-setup - Done
- Optimize speed - Done
- Keep up in dev env - Done
- Use production migration to build-up - Done
**- RAM folder - Not yet**
## Basic tests - (5)
- Axios, not supertest (configure global instance that doesn't throw when HTTP=!200)
- Generate JWT secret for authentication -
- Assert for objects including the status
- Structure Describes by route and stories
- Keep unit tests good practices (AAA, name)
## Tests isolation (8)
- Intercept any outside calls, isolation
- Define network interception in beforeEach, cleanup in afterEach
- Disable all network requests except those which were explicitly defined (nock.enableNetConnect)
- Once you have a default, but need to override in a specific test - Create a unique request pattern or remove a global scope
- Simulate collaborator failures
- Explicitly define request schema to test the outgoing call (how explicit to be?)
- Record requests to discover various integration patterns and collaborator to build the tests upon
## Dealing with data (7)
- Each test act on its own records - Avoid coupling
- Seed only metadata -
- Clean-up only in the end -
- Use randomizing factory (e.g. Rosie like) -
- Check response schema -
- Test large responses -
**- More than single page in paging** (Should write)
**- Insert two in parallel** (Should write)
## Error handling and metrics
- Test various error handling flows and outcome
**- Test metrics**
- Test OpenAPI documentation
- Test the contracts
- Test for memory leaks
- Tag pure black-box tests to reuse against remote environment
- Test DB/ORM migrations
## Message queue related testing (8)
- Flatten the test, get rid of callbacks
- Thoughtful decision about real vs fake
- Test a poisoned message
- Test idempotency
- Test DLQ
- E2E (Retry, DLQ, names)
- Test ACK
- Test start failure, Zombie
- Test for metadata, JWT
## Workflow (6)
- Tune a test runner for ongoing testing
- Start with integration tests
- Focus on feature coverage
- Test various error handling
- The KATA
- Slow test
- When unit
## Other ideas
- Parallelize requests
More will come here. Suggest more?
Contributor guide
Assessment
This issue has not been assessed yet.