BDD/TDD

Hi @kytrinyx, 

I saw this first draft code, and I wanted to suggest some changes in approach.

I know/assume this isn't a serious project, but I've found this approach to testing and building an application to be pretty common in Ruby, and I get in lots of debates over it.  I'm a big advocate for TDD, and the "BDD cycle" in the appropriate places.  So instead of just talking about it, I wanted to offer actual code.

Here's what I did:

1.  I flipped them over to minitest/spec.  Using the minitest unit tests are just fine, but the specs are helpful for this sort of tests are you can define "contexts" around different situations... including providing concrete examples like your fixture files.  This is more of a "style" thing to make the file output easier to read, but don't think I'm saying this is required.  
2.  Just to point out:  All of your original tests are still there, and they pass.
3.  I separated your tests into their own "describe" block.  They were a great BDD test.  They stayed red as I was going red/green with unit tests, and I knew I was done with everything went green.
4.  I "rebuilt" the code with TDD, though I refactored back into your original code.
5.  I used mocha to mock different situations.  I know, I know, uttering the word "mock" immediately causes some developers to jump on their respective soapboxes... but the mock here isn't important.  I'm using the mocking library to cut down on the code it would take to build objects manually, stubbing methods instead of asserting that x called y which then called z.

So if the original code is the same, what's the big deal?  A few things...

1.  One of the easiest tests I do when evaluating the safety to change code is to try to break the tests.  With this one-example approach, I was able to change the production code to a few hardcoded examples.  All tests were green, but the application was obviously busted.  https://github.com/darrencauthon/phone_book/commit/5a14edbcca57f6aae98b02208441c96b06592089

2.  By adding unit tests (or at least by pumping more than one example through the tests), I think one would find it very difficult to break the application code like I did to your original commit.

3.  I believe that the unit tests will make future changes easier.  They allow the developer to isolate specific situations, whether they be very fine-grained changes or wider examples.  Or in other words... developers won't have to create a different fixture file if they want to test something specific, or alter an existing fixture.  We want tests to be stable. :smile: