From 656df66a6c7b6be91285769c03024d3b1c2601d8 Mon Sep 17 00:00:00 2001
From: Stefano Magni <nori.ste.magni@gmail.com>
Date: Mon, 12 Aug 2019 15:29:17 +0200
Subject: [PATCH] Remove the 2.7 chapter

The 2.7 chapter is a duplication of the 1.9 one
---
 readme.md | 60 +------------------------------------------------------
 1 file changed, 1 insertion(+), 59 deletions(-)

diff --git a/readme.md b/readme.md
index 9ff0db8f..b46adee3 100644
--- a/readme.md
+++ b/readme.md
@@ -865,64 +865,6 @@ Credit:: <a href="https://github.com/TheHollidayInn" data-href="https://github.c
 
 </details>
 
-<br/>
-
-## ⚪ ️2.7 Avoid global test fixtures and seeds, add data per-test
-
-:white_check_mark: **Do:** Going by the golden rule (bullet 0), 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 (see “Component testing” bullet), however, test complexity is a much painful sorrow that should govern other considerations most of the time. 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/>
-
-
-❌ **Otherwise:** Few tests fail, a deployment is aborted, our team is going to spend precious time now, do we have a bug? let’s investigate, oh no — it seems that two tests were mutating the same seed data
-
-
-<br/>
-
-<details><summary>✏ <b>Code Examples</b></summary>
-
-<br/>
-
-### :thumbsdown: Anti Pattern Example: tests are not independent and rely on some global hook to feed global DB 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 :[
-});
-
-```
-<br/>
-
-### :clap: Doing It Right Example: We can stay within the test, 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);
-});
-
-```
-
-</details>
-
-
-
-
 
 <br/><br/>
 
@@ -1912,4 +1854,4 @@ A5NDY3LDE1OTcyNDA3NzUsMjEwMzQzMDE2NiwtMzc1NjYzODQs
 LTEyODY1MzE2MDAsLTI5NzUwMjYyMyw0MzUxOTU4ODAsMTc2NT
 k2NzEzMCw3OTQ4ODg1MTcsLTE4MDA1NTUwMDYsOTM1MTI0ODc5
 LDc3NTU2MTAxOSwtMjEwMzIxODMzM119
--->
\ No newline at end of file
+-->