Files
nodebestpractices/sections/testingandquality/avoid-global-test-fixture.md
2021-03-03 22:35:16 +02:00

55 lines
2.4 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Avoid global test fixtures and seeds, add data per-test
<br/><br/>
### One Paragraph Explainer
Going by the golden testing rule - keep test cases dead-simple, each test should add and act on its own set of DB rows to prevent coupling and easily reason about the test flow. In reality, this is often violated by testers who seed the DB with data before running the tests (also known as test fixture) for the sake of performance improvement. While performance is indeed a valid concernit can be mitigated (e.g. In-memory DB, see “Component testing” bullet), however, test complexity is a much painful sorrow that should govern other considerations. Practically, make each test case explicitly add the DB records it needs and act only on those records. If performance becomes a critical concerna balanced compromise might come in the form of seeding the only suite of tests that are not mutating data (e.g. queries)
<br/><br/>
### Code example: each test acts on its own set of data
```javascript
it('When updating site name, get successful confirmation', async () => {
//Arrange - test is adding a fresh new records and acting on the records only
const siteUnderTest = await SiteService.addSite({
name: 'siteForUpdateTest'
});
//Act
const updateNameResult = await SiteService.changeName(siteUnderTest, 'newName');
//Assert
expect(updateNameResult).to.be(true);
});
```
<br/><br/>
### Code Example Anti Pattern: tests are not independent and assume the existence of some pre-configured data
```javascript
before(() => {
//Arrange - adding sites and admins data to our DB. Where is the data? outside. At some external json or migration framework
await DB.AddSeedDataFromJson('seed.json');
});
it('When updating site name, get successful confirmation', async () => {
//Arrange - I know that site name 'portal' exists - I saw it in the seed files
const siteToUpdate = await SiteService.getSiteByName('Portal');
//Act
const updateNameResult = await SiteService.changeName(siteToUpdate, 'newName');
//Assert
expect(updateNameResult).to.be(true);
});
it('When querying by site name, get the right site', async () => {
//Act - I know that site name 'portal' exists - I saw it in the seed files
const siteToCheck = await SiteService.getSiteByName('Portal');
//Assert
expect(siteToCheck.name).to.be.equal('Portal'); //Failure! The previous test change the name :[
});
```