
In computer programming **pure function** is a function that satisfies two conditions:

* It is **deterministic**, which means that for any given input it will always return same output.
* It has no **side effects**. Which means it doesn't change outside world. Doesn't perform input/output operation or change global variables.

The most simple example of pure function is an **identity** function:

```js
const identity = (x) => x;
```

For any given `x` it will return its value, so it is **determenistic**.

It also has to **side-effects** as it doesn't interact with global environment.

More practical example of pure function could be `sum` that will return sum of its arguments:

```js
const sum = (x, y) => x + y;
```

This function is pure as well. For any given `x` and `y` it will always return same result.

Contrary to that `Math.random()` is an example of **nondeterministic function**.

Every time you call it - you can get different result.


```js
Math.random();  // 0.30498094536268224
Math.random();  // 0.30387681124534656
Math.random();  // 0.03712550164644983
```

Any function that will use result of `Math.random()` execution inside of it will also become **nondeterministic** and **impure**.

Another example of an **impure** function is function with **side effects**.

```js
let x = 0;

const increment = () => {
  x = x + 1;
  return x;
}

increment() // 1
increment() // 2
increment() // 3
increment() // 4
```

Here function `increment` is **impure** because it alters the global variable `x`.

Every time you will call it you will get different result.

## Benefits Of Pure Functions

**Pure functions** have a bunch of benefits over **impure** ones.

First of all **pure functions** are easier to read. Pure functions tend to be small and do one thing.

**Pure functions** are easier to test. Since there are no side effects and the output depends only on the input, your test cases are straightforward.

**Pure functions** are very composable. In functional programming it is very common to compose small pure functions into more complex ones.

```js
const add = (a, b) => a + b;
const mult = (a, b) => a * b;
add(2, mult(3, 5))
// 17
```

Here we passed the result of `mult` as a second argument of our `add` function.

**Pure functions** are memoizable. That means that you can save result of your function execution to use it later.

Pure Functions And Side Effects


__OCP__ states that software entities (classes, modules, functions) should be open for extension, but closed for modification. Let's figure out what exactly does it mean…

That basically means that you should write your modules in a way that wouldn't require you to __modify__ it's code in order to __extend__ it's behaviour.

![open/closed principle](/open_closed_1.png)

## Let's Get To Real World Example

I mean imaginary world example. Imagine you have a machine that can make _chocolate-chip_ and _fortune_ cookies.

```js
describe('CookieMachine', function(){
  describe('#makeCookie', function(){
    it('returns requested cookie when requested cookie with known recipy', function(){
      const cookieMachine = new CookieMachine();

      expect(cookieMachine.makeCookie('chocolate-chip-cookie')).toEqual('Chocolate chip cookie');
      expect(cookieMachine.makeCookie('fortune-cookie')).toEqual('Fortune cookie');
    });

    it('raises an error when requested cookie with unknown recipy', function(){
      const cookieMachine = new CookieMachine();

      expect(function(){ cookieMachine.makeCookie('unknown-cookie'); }).toThrow('Unknown cookie type.');
    })
  });
});
```

Here is `CookieMachine` itself:

```js
class CookieMachine{
  constructor(){
    // Sophisticated setup process
  }

  makeCookie(cookieType){
    switch(cookieType){
      case 'chocolate-chip-cookie':
        return 'Chocolate chip cookie';
      case 'fortune-cookie':
        return 'Fortune cookie';
      default:
        throw 'Unknown cookie type.';
    }
  }
}

```

Let's imagine that it's Christmas season and we need to cook Pepper cookies. See, we violated OCP and now we have to change `CookieMachine` code and add new `case` block.

## Let's Fix It

We'll introduce an abstraction, `CookieRecipy`:

```js
class CookieRecipy{
  constructor(){
    // Sophisticated setup process
  }

  cook(){
    // Abstract cooking process  
  }
}

class ChocolateChipCookieRecipy extends CookieRecipy{
  constructor(){
    super();
    this.cookieType = 'chocolate-chip-cookie'
    // Sophisticated setup process
  }

  cook(){
    return 'Chocolate chip cookie';
  }
}

class FortuneCookieRecipy extends CookieRecipy{
  constructor(){
    super();
    this.cookieType = 'fortune-cookie'
    // Sophisticated setup process
  }

  cook(){
    return 'Fortune cookie';
  }
}

class PepperCookieRecipy extends CookieRecipy{
  constructor(){
    super();
    this.cookieType = 'pepper-cookie'
    // Sophisticated setup process
  }

  cook(){
    return 'Pepper cookie';
  }
}
```

And also we'll modify `CookieMachine` to accept these recipes in constructor. We will use the `reduce` method to reduce the recipes list to an object with cookie types for keys:

```js
class CookieMachine{
  constructor(...recipes){
    this._recipes = recipes.reduce(function(accumulator, item){
      accumulator[item.cookieType] = item;
      return accumulator;
    }, {});
  }

  makeCookie(cookieType){
    if(this._recipes.hasOwnProperty(cookieType)){
      return this._recipes[cookieType].cook();
    }
    throw 'Unknown cookie type.'
  }
}
```

Great, now if we want to cook some new cookie – we just create new cookie recipe.

## Let's Update The Specs

Now we have to pass cookie types upon `CookieMachine` creation.

```js
describe('CookieMachine', function(){
  describe('#makeCookie', function(){
    it('returns requested cookie when requested cookie with known recipy', function(){
      const cookieMachine = new CookieMachine(new ChocolateChipCookieRecipy(), new FortuneCookieRecipy(), new PepperCookieRecipy());

      expect(cookieMachine.makeCookie('chocolate-chip-cookie')).toEqual('Chocolate chip cookie');
      expect(cookieMachine.makeCookie('fortune-cookie')).toEqual('Fortune cookie');
      expect(cookieMachine.makeCookie('pepper-cookie')).toEqual('Pepper cookie');
    });

    it('raises an error when requested cookie with unknown recipy', function(){
      const cookieMachine = new CookieMachine();

      expect(function(){ cookieMachine.makeCookie('unknown-cookie'); }).toThrow('Unknown cookie type.');
    })
  });
});
```

Great, test pass now and we can cook ANY COOKIES WE WANT!


Open/Closed Principle - SOLID


I was refactoring specs of some Rails application when I decided to mock the `ImageUploader` class of CarierWave. I wanted to be able to check for specific image url. __But was it a good idea?__

## No, Don't Do It

I know it might be tempting to mock libraries that make database or network calls to make specs run faster, but that's not what test doubles are meant for.

Test doubles are meant to help you create practical and convenient interfaces between parts of your application.

![mocking](/dont_mock_1.png)

Imagine you have to create some _thing_ that you should integrate in already existing code.

Using test double you can easily check if the interface of the _thing_ (that is not implemented yet) is clear and easy to use. And if not – it's cheap to throw it away and start over.

Now looking from __this perspective__ you should see that mocking third-party _thing_ doesn't make any sense.

But not only it's meaningless…

## Wait, What Perspective?

I mean, __TDD is not only about testing__, it's also about design. Mocking external lib won't help you to create good design, because you don't have any control over it.

The idea is to use mocks as quick and rough prototypes, to see how your _thing_ will be integrated into existing code. If you see that the interface is not very handy – you just write the mock differently, with different methods or with different method signatures.

So you just prototype your interface first and write your implementation later.

Now if you apply this logic to mocking external library (which interface you cannot change), you'll see that it makes zero sense.

Got it? Let's continue…

## It's Also Harmful

Most obvious danger is getting false positives (or negatives, depends on perspective). In other words your test will pass where the actual thing won't work. Either because you've mocked it in a wrong way or the library you were mocking changed slightly after an upgrade.

Also by mocking an external lib you are binding yourself to a specific implementation and it will be much harder to change the library in the future.

Another downside is that you might end up with a lot of excessive code that doesn't bring any value. It can also make it harder to understand what is going on in your code.

## But HTTP And Database Calls Make My Tests Slow

If that's really a problem – __create wrappers__ around that third party _thing_.

Don't forget to write integration tests for that wrappers.

As a bonus you'll make it clear what functions of that external lib you __really use__, and it will be much easier to replace that dependency later.

## Summary

In my case I went with using `ImageUploader` directly, writing a wrapper for it would be just crazy.

I hope this small article will help you avoid this caveat.

If you are interested in further reading on that topic – here are some more articles:

- http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html
- http://www.markhneedham.com/blog/2009/12/13/tdd-only-mock-types-you-own
- http://blog.8thlight.com/eric-smith/2011/10/27/thats-not-yours.html
- http://stackoverflow.com/questions/1906344/should-you-only-mock-types-you-own


Don't Mock What You Don't Own


In __1988__ Barbara Liskov wrote something that now stands for __L__ in __SOLID__ principles. Let's dive in and learn what is it and how does it relate to __TDD__.

Here is the original formulation: _"If for each object __o1__ of type __S__ there is an object __o2__ of type __T__ such that for all programs __P__ defined in terms of __T__, the behaviour of __P__ is unchanged when __o1__ is substituted for __o2__ then __S__ is a subtype of __T__."_

Simply speaking: _"Derived class objects must be substitutable for the base class objects. That means objects of the derived class must behave in a manner consistent with the promises made in the base class contract."_

Speaking even more simply: _"Derived class objects should __complement__, not __substitute__ base class behaviour."_

![liskov](/liskov_1.png)

LSP can also be described as a counter-example of [Duck Test](https://en.wikipedia.org/wiki/Duck_test): _"If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction"_

## So, In Real World

If you have some class __Foo__ and a derived class __SubFoo__, then if you change all the notions of __Foo__ class to __SubFoo__ – the program execution shouldn't change, as __SubFoo__ doesn't change the __Foo__ class functionality, and only extends it.

## Let's See The Example

Getting back to ducks. Let's describe a `Duck`. We have very low expectations on it. We only expect it to be able to quack and nothing else.

```js
describe('Duck', function(){
  describe('#quack', function(){
    it('produces "Quack" sound', function(){
      const duck = new Duck();
      expect(duck.quack()).toEqual('Quack');
    });
  });
});
```

Fine, now lets define the basic duck.

```js
class Duck{
  constructor(){
    // Duck initialization process
  }

  quack(){
    return 'Quack';
  }
}
```

We run the spec and it passes. Cool, now let's create a derived class `MechanicalDuck`. It should also be able to quack. The only difference is that it needs batteries to operate.

```js
class MechanicalDuck extends Duck{
  constructor(battery=null){
    super();
    this._battery = battery;
  }

  quack(){
    if(!this._battery){
      throw 'Need battery to operate.';
    }
    return 'Quack';
  }
}
```

Now according to LSP, we should be able to safely change instances of base class to instances of derived class. Let's change our spec a bit and try to use `MechanicalDuck` instead of `Duck`.

Uh-oh, test failed. `MechanicalDuck` needs battery to quack. So `MechanicalDuck` here is clearly not a duck. Even though it's interface might look similar, it's __behaviour__ is totally different.

## But What Would Be A Proper Subclass?

In our case it might be a `FemaleDuck`. Let's implement it.

```js
class FemaleDuck extends Duck{
  constructor(){
    super();
    // Initialization of female stuff
    this._butt = new FemaleDuckButt();
  }

  layAnEgg(){
    const egg = this._butt.layAnEgg();
    return egg;
  } 
}
```

`FemaleDuck` will successfully pass the duck test, as we didn't change the behaviour, but only extended it. Our duck can lay eggs, hurray!


Programming

Pure Functions And Side Effects

Open/Closed Principle - SOLID

Don't Mock What You Don't Own

Liskov Substitution Principle - SOLID