RED - Introduces GameOfLife class

If you can't get the test to pass quickly, focus on changing the
*message* the test provides. This allows you to see if you're going in
the right direction.

By defining a class for GameOfLife, I expect that the message will
change from a "NameError" to something (hopefully) more useful in
guiding my implementation.

Expected Result of `bundle exec ruby test/all.rb`
=================================================

> # Running:
>
> E
>
> Finished in 0.001128s, 886.5248 runs/s, 0.0000 assertions/s.
>
>   1) Error:
> TestGameOfLife#test_a_con_at_5_5_with_no_neighbors_dies_after_one_day:
> ArgumentError: wrong number of arguments (1 for 0)
>     test/all.rb:11:in `initialize'
>     test/all.rb:11:in `new'
>     test/all.rb:11:in `test_a_con_at_5_5_with_no_neighbors_dies_after_one_day'
>
> 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips

Oh hey! Look at that! We are now getting an ArgumentError! These two
lines tell me what to do:$

> ArgumentError: wrong number of arguments (1 for 0)
>     test/all.rb:11:in `initialize'

This tells me that `test/all.rb` on line 11 is trying to call a method
named initialize with an argument, but the method's definition doesn't
take an argument.

When we *look* at line 11, we see the following:

> game = GameOfLife.new(population)

What! Where's 'initialize'! It's no where in there! Let's look one line
further in the error message:

> test/all.rb:11:in `new'

Ah-ha! Initialize and new seem to have some kind of relationship. Let's
look into what new does in ruby¹, it turns out new:

* Allocates an instance of the GameOfLife class
* Calls initialize on that instance with the arguments passed to new.
* Returns that instance

Let's define an initialize method!

Footnotes
=========
¹ Class new: http://ruby-doc.org/core-2.0.0/Class.html#method-i-new
Red - Defines an initialize method on GameOfLife

Now we're getting somewhere! We've defined the initialize method and
stated it takes a single argument named population.

Arguments are how we provide data to a method. The names used in an
argument and the names used to call the argument do not need to match,
but in this case they happen to.

Let's see what the tests think about our changes:

Expected Result of `bundle exec ruby test/all.rb`
=================================================
> Run options: --seed 36241
>
> # Running:
>
> E
>
> Finished in 0.001210s, 826.4463 runs/s, 0.0000 assertions/s.
>
>   1) Error:
> TestGameOfLife#test_a_con_at_5_5_with_no_neighbors_dies_after_one_day:
> NoMethodError: undefined method `run' for #<GameOfLife:0x007fea59aa8e80>
>     test/all.rb:14:in `test_a_con_at_5_5_with_no_neighbors_dies_after_one_day'
>
> 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips

Now we get a NoMethodError, what does this one tell us?

> test/all.rb:14:in `test_a_con_at_5_5_with_no_neighbors_dies_after_one_day'
Tells us the code causing the error is at line 14 in test/all.rb

> NoMethodError: undefined method `run' for #<GameOfLife:0x007fea59aa8e80>
Tells us there is not a method named "run" defined on the GameOfLife class.

When we look at lines 13 and 14 in test/all.rb we see:

13 game = GameOfLife.new(population)
14 game.run(1)

The variable named game stores an instance of GameOfLife.new and that seems to
be working, yet on 14 we call run *on* the variable named game *with* the number 1.

Because our GameOfLife class doesn't have an instance method named run, this is
causing our test to fail.

To fix this we have to define a run method on the GameOfLife class. Seeing the
run method is expected to take one argument, we *could* include the argument in
our initial definition, or we could define the method and let the tests tell us
to define the argument. Different practitioners of TDD have different opinions
about this. Personally, it doesn't make much of a difference. Do what feels
right. If something bad happens take a smaller step.
RED - Defines run method

Notice we haven't implemented any part of the run method yet. Our goal
is to get to green as quickly as possible, and taking the time to
pontificate about how the run method may or may not work would interfere
with our ability to get to green.

We still have at least one error message to go though:

Expected Result of `bundle exec ruby test/all.rb`
=================================================
> Run options: --seed 19266
>
> # Running:
>
> E
>
> Finished in 0.001011s, 989.1197 runs/s, 0.0000 assertions/s.
>
>   1) Error:
> TestGameOfLife#test_a_con_at_5_5_with_no_neighbors_dies_after_one_day:
> NoMethodError: undefined method `population' for #<GameOfLife:0x007f9f92b887b8>
>     test/all.rb:20:in `test_a_con_at_5_5_with_no_neighbors_dies_after_one_day'
>
> 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips

Here we see another undefined method error. By now we know the drill: Look at
line 20 in test/all.rb and write a method definition that matches the implied
interface.
RED - Defines population instance method on GameOfLife

Surely, surely we must have done everything we need to get this test green,
right?

Nope! We're still at a failing test! Good gravy! How! What! As we program, we
deceive ourselves into thinking we know how much work it takes to make working
software. Even taking the most direct route from Red to Green can be several
steps, *even without implementing any of the underlying behavior*! This is why
it's so important to aggressively avoid doing more work than necessary when
switching from Red to Green. The longer it takes to transition between those
states the more likely we'll introduce some amount of confounding or confusing
logic in our implementation.

So, what are the tests telling us?

Expected Result of `bundle exec ruby test/all.rb`
=================================================
> Run options: --seed 663
>
> # Running:
>
> E
>
> Finished in 0.001065s, 938.9671 runs/s, 0.0000 assertions/s.
>
>   1) Error:
> TestGameOfLife#test_a_con_at_5_5_with_no_neighbors_dies_after_one_day:
> NoMethodError: undefined method `include?' for nil:NilClass
>     test/all.rb:25:in `test_a_con_at_5_5_with_no_neighbors_dies_after_one_day'
>
> 1 runs, 0 assertions, 0 failures, 1 errors, 0 skips

Looks like there's an undefined method include? for nil:NilClass. What should we do?

If we were to follow our previous pattern of defining a method on the indicated
class we would define a method on NilClass. How would that even work?

Instead, we need to look at the line of code our test points out, line 25 in
test/all.rb:

> refute(game.population.include?(con), failure_message)

Here we see the word "include?" and the the parenthesis indicate it's a method.
We also notice there is a `.` between include? and population, which tells us
include? is being called *on* population (and with `con`).

But what is population? It doesn't have any parenthesis, so is it not a method?
It has a `.`, which indicates it *is* *on* game...

In fact, it is a method. In Ruby, it's common for methods that don't take any
arguments to not include their parenthesis both when being called and when
being defined.

To break down how this line is interpreted we'd see that:

1. The method population is called on game.
2. The method include? is called on the result of the population method with a con.
3. The result of calling game.poulation.include?(con) is passed as the first argument to refute.
4. refute checks if the result was true and if it is, fails the test with the
   message given as it's second argument.

As we become better programmers in a given language, we want to constantly
improve the accuracy and speed with which we can understand a line of code such
as this, without succumbing to over-precision. It can be difficult to choose
where to draw the line of precision, especially when our understanding of a
line of code is inaccurate.

Given the above breakdown and the error message we may determine this failure
message is caused by the population method returning a value of nil.

Given a method named include? is called on the result of population, we may
ascertain that `population` could return an Array (or something else that
responds to include?, but we'll stick with Array for now).

Given the refute statement, we may infer the Array returned *cannot include*
the con we started with.

Let's make population return an empty Array.
GREEN - Alone Con at 5,5 dies after 1 day

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Expected Result of `bundle exec ruby test/all.rb`
=================================================
> Run options: --seed 62774
>
> # Running:
>
> .
>
> Finished in 0.001340s, 746.2687 runs/s, 746.2687 assertions/s.
>
> 1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

One of the idioms I dislike in Ruby is implicit returns. This means that
the *last expression evaluated in a method is returned from that
method*. I much prefer typing the word `return`, but it's important to
conform to the communities preferred style when writing code.