Merge pull request #372 from i0natan/test-avoid-fixture

New BP: Bullet 4.4 - add data per test

README.md

@@ -444,16 +444,18 @@ All statements above will return false if used with `===`
 
 <br/><br/>
 
-## ![✔] 4.4 Carefully choose your CI platform (Jenkins vs CircleCI vs Travis vs Rest of the world)
+## ![✔] 4.4 Avoid global test fixtures and seeds, add data per-test
 
-**TL;DR:** Your continuous integration platform (CICD) will host all the quality tools (e.g test, lint) so it should come with a vibrant ecosystem of plugins. [Jenkins](https://jenkins.io/) used to be the default for many projects as it has the biggest community along with a very powerful platform at the price of complex setup that demands a steep learning curve. Nowadays, it has become much easier to set up a CI solution using SaaS tools like [CircleCI](https://circleci.com) and others. These tools allow crafting a flexible CI pipeline without the burden of managing the whole infrastructure. Eventually, it's a trade-off between robustness and speed - choose your side carefully
+**TL;DR:** To prevent tests coupling and easily reason about the test flow, each test should add and act on its own set of DB rows. Whenever a test needs to pull or assume the existence of some DB data - it must explicitly add that data and avoid mutating any other records
 
-**Otherwise:** Choosing some niche vendor might get you blocked once you need some advanced customization. On the other hand, going with Jenkins might burn precious time on infrastructure setup
+**Otherwise:** Consider a scenario where deployment is aborted due to failing tests, team is now going to spend precious investigation time that ends in a sad conclusion: the system works well, the tests however interfere with each other and break the build
 
-🔗 [**Read More: Choosing CI platform**](/sections/testingandquality/citools.md)
+🔗 [**Read More: Avoid global test fixtures**](/sections/testingandquality/avoid-global-test-fixture.md)
 
 <br/><br/>
 
+
+
 ## ![✔] 4.5 Constantly inspect for vulnerable dependencies
 
 **TL;DR:** Even the most reputable dependencies such as Express have known vulnerabilities. This can get easily tamed using community and commercial tools such as 🔗 [npm audit](https://docs.npmjs.com/cli/audit) and 🔗 [snyk.io](https://snyk.io) that can be invoked from your CI on every build
@@ -502,8 +504,19 @@ All statements above will return false if used with `===`
 
 🔗 [**Read More: Refactoring!**](/sections/testingandquality/refactoring.md)
 
+<br/><br/>
+
+## ![✔] 4.11 Carefully choose your CI platform (Jenkins vs CircleCI vs Travis vs Rest of the world)
+
+**TL;DR:** Your continuous integration platform (CICD) will host all the quality tools (e.g test, lint) so it should come with a vibrant ecosystem of plugins. [Jenkins](https://jenkins.io/) used to be the default for many projects as it has the biggest community along with a very powerful platform at the price of complex setup that demands a steep learning curve. Nowadays, it has become much easier to set up a CI solution using SaaS tools like [CircleCI](https://circleci.com) and others. These tools allow crafting a flexible CI pipeline without the burden of managing the whole infrastructure. Eventually, it's a trade-off between robustness and speed - choose your side carefully
+
+**Otherwise:** Choosing some niche vendor might get you blocked once you need some advanced customization. On the other hand, going with Jenkins might burn precious time on infrastructure setup
+
+🔗 [**Read More: Choosing CI platform**](/sections/testingandquality/citools.md)
+
 <br/><br/><br/>
 
+
 <p align="right"><a href="#table-of-contents">⬆ Return to top</a></p>
 
 # `5. Going To Production Practices`

sections/testingandquality/avoid-global-test-fixture.md

@@ -0,0 +1,42 @@
+# 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 concern — it 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 concern — a 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 () => {
+  //test is adding a fresh new records and acting on the records only
+  const siteUnderTest = await SiteService.addSite({
+    name: "siteForUpdateTest"
+  });
+  const updateNameResult = await SiteService.changeName(siteUnderTest, "newName");
+  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(() => {
+  //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 () => {
+  //I know that site name "portal" exists - I saw it in the seed files
+  const siteToUpdate = await SiteService.getSiteByName("Portal");
+  const updateNameResult = await SiteService.changeName(siteToUpdate, "newName");
+  expect(updateNameResult).to.be(true);
+});
+it("When querying by site name, get the right site", async () => {
+  //I know that site name "portal" exists - I saw it in the seed files
+  const siteToCheck = await SiteService.getSiteByName("Portal");
+  expect(siteToCheck.name).to.be.equal("Portal"); //Failure! The previous test change the name :[
+});
+```