diff --git a/README.md b/README.md
index ac1815a..016eacc 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,6 @@
-
 **Author**: [@skibinska](https://github.com/skibinska)  
 **Maintainer**: [@skibinska](https://github.com/skibinska)
 
-
 # FizzBuzz
 
 Using Test Driven Development to solve FizzBuzz.
@@ -17,24 +15,26 @@ One student starts by creating a single failing test and then the other writes c
 
 Before we start, and for the ones who are not familiar with the [FizzBuzz problem](https://en.wikipedia.org/wiki/Fizz_buzz), the idea is to write a function that takes a number and either returns the number _or_:
 
-- for multiples of 3 returns the word **Fizz** instead of the number
-- for multiples of 5 returns the word **Buzz** instead of the number
-- for multiples of 3 and 5 returns the word **FizzBuzz**.
+- for multiples of 3 we will display the word **Fizz** instead of the number,
+- for multiples of 5 we will output **Buzz** instead of the number and
+- for multiples of 3 and 5 we will display **FizzBuzz**.
 
 An example:
-```javascript
+
+```js
 fizzbuzz(1); // Output: 1
 fizzbuzz(2); // Output: 2
 fizzbuzz(3); // Output: Fizz
 ```
+
 ## Defining the tool
 
 **Test-driven development (TDD)** is a methodology or a software development process that is based on the **repetition** of the following tasks:
 
-- write a simple test that defines an expected functionality/outcome
-- make the test fail (it will fail as we haven’t written any code just yet!)
-- write your code as simple as possible to make your test pass
-- refactor your code and run the same test again (it should pass as even though is refactored the functionality should be the same).
+* write a simple test that defines an expected functionality/outcome
+* make the test fail (it will fail as we haven’t written any code just yet!)
+* write your code as simple as possible to make your test pass
+* refactor your code and run the same test again (it should pass as even though is refactored the functionality should be the same).
 
 This is also called the **Red-Green-Refactor** cycle of TDD.
 
@@ -42,12 +42,39 @@ This is also called the **Red-Green-Refactor** cycle of TDD.
 
 > The key concept is to write your **unit test before** you write a line of implementation **code**.
 
+## Tape Testing terminologies
+
+* t.equal(actual, expected, msg)
+
+  Compares flat data structure and they have to be of the same data type. It uses the === operator.
+
+* t.deepEqual(actual, expected, msg)
+
+  It is used for testing nested data structure. Deep equal would look into all items within the object no matter how deeply nested they are and check that all the items are the same. It uses the === operator.
+
+  See example below for an example of a nested object.
+
+  ```js
+  var object = {
+    baz: {
+      foo: {
+        bar: 5
+      }
+    }
+  }
+  ```
+
+* t.end(err)
+
+  Declare the end of a test explicitly. If err is passed in t.end will assert that it is falsey.
+
 ## Let’s get started!
 
 ### 1. Clone
 
 Clone the repository by copy-pasting the following command into your terminal:
-```
+
+```js
 git clone https://github.com/foundersandcoders/fizzbuzz.git && cd fizzbuzz
 ```
 
@@ -63,21 +90,22 @@ Run the example test with:
 
 We will start by writing the most simple unit test of all, a unit test that will output the first number:
 
-```javascript
-test('Testing fizzbuzz return value', function(t) {
+```js
+test("Testing fizzbuzz return value", function(t) {
   var actual = fizzbuzz(1);
   var expected = 1;
-  t.equal(actual, expected, 'Should return 1 when given 1');
+  t.equal(actual, expected, "Should return 1 when given 1");
   t.end();
 });
 ```
+
 **Run the test with `npm test`**
 
 Our first fail is because **fizzbuzz doesn't return anything**.
 
-So we need to add to the function in  `index.js`:
+So we need to add to the function in `index.js`:
 
-```javascript
+```js
 function fizzbuzz() {
   return 1;
 }
@@ -93,21 +121,22 @@ Let’s now get the first two numbers.
 
 Add a unit test to `test.js` to check if our function returns 2:
 
-```javascript
-test('Testing fizzbuzz return value', function(t) {
+```js
+test("Testing fizzbuzz return value", function(t) {
   var actual = fizzbuzz(2);
   var expected = 2;
-  t.equal(actual, expected, 'Should return 2 when given 2');
+  t.equal(actual, expected, "Should return 2 when given 2");
   t.end();
 });
 ```
+
 The test fails because it expects **2** but gets **1**.
 
 We need to write just enough code to pass this test.
 
 Update `index.js`:
 
-```javascript
+```js
 function fizzbuzz(number) {
   if (number === 2) {
     return 2;
@@ -115,6 +144,7 @@ function fizzbuzz(number) {
   return 1;
 }
 ```
+
 That does just enough to pass the test.
 
 #### Iteration 3
@@ -123,29 +153,30 @@ Well, that was easy, but we're not quite there yet. Let’s now get the first th
 
 Let's write a test:
 
-```javascript
-test('Testing fizzbuzz return value', function(t) {
+```js
+test("Testing fizzbuzz return value", function(t) {
   var actual = fizzbuzz(3);
-  var expected = 'Fizz';
-  t.equal(actual, expected, 'Should return Fizz when given 3');
+  var expected = "Fizz";
+  t.equal(actual, expected, "Should return Fizz when given 3");
   t.end();
 });
 ```
+
 The test fails because it expects **Fizz** but gets **1**.
 
 Let's write enough code to pass this test.
 
-```javascript
+```js
 function fizzbuzz(number) {
   if (number === 3) {
     return "Fizz";
-  }
-  else if (number === 2) {
+  } else if (number === 2) {
     return 2;
   }
   return 1;
 }
 ```
+
 Good stuff; our tests pass but our code is getting harder to read (this is where the last step in each iteration comes on board: refactoring),
 
 > **refactoring** means rearranging our code so it's easily readable by us (humans);
@@ -154,22 +185,22 @@ so how can we make this easier to read?
 
 I’m thinking of removing one of the if/else statements, let’s try that:
 
-```javascript
+```js
 function fizzbuzz(number) {
- if (number === 3) {
+  if (number === 3) {
     return "Fizz";
-  }
-  else {
+  } else {
     return number;
   }
 }
 ```
+
 Isn’t this easier to read? Yes! Running our unit tests confirm that we haven’t broken anything as all of them still pass.
 
 Once you have your process nailed:
 
-- Write a test and watch it fail
-- Write just enough code to pass the test (without breaking any other test that was already passing!)
+* Write a test and watch it fail
+* Write just enough code to pass the test (without breaking any other test that was already passing!)
 
 Continue writing tests and refactoring until you have a `fizzbuzz` function that works for any number.