Hardcoded environment to 'test' in config file

Made ENV['RACK_ENV'] = 'test'.  We are now hard-coded into
a test environment, so my specs will be able to insert things into the
right database.

Question: what in my code is dictating that the specs need to
insert into a database that ends in _test?
Deleted a routes_spec and addes user_spec to spec folder

Deleted the routes_spec spike. Now that I know how to set up tests, I don't need the spike anymore.  Added a user_spec, using the rake generate:spec command. That is a fun one! Am now ready to begin serious testing.
Tested User.new() function

This tests activeRecord and ruby classes.

I expected User.new to create a new instance of the user object.   In my terms, the User class is a blueprint.  The instance is the house you build from that blueprint.

User inherits from the Activerecord class.
  In my terms, inheritance means that we are actually using the activeRecord blueprint.  ActiveRecord is a general blueprint, like the fact that a car has four wheels.  Then the User class is like a specific make and model of car.  Usually, when people talk about their car, they say things like my 'chevy' or my 'prius.'  So when you are referring to specific type of car, you refer to it by the more specific name, which is why in code we talk about User.new instead of Activerecord.User.new.

Activerecord is not actually a more general type of car. Instead, you know how it takes a whole sea of paperwork to keep your car running?  It takes a license and registration, and insurance, and records upon records, and you have to tell a whole bunch of people that you own a car and that you are maintaining it.  Wouldn't it be nice if you had a manager that took care of that stuff for you?  Activerecord does that.

When you build a car, you get to do all of the fun stuff of actually building it, and Activerecord takes care of keeping track of every car you build.

Now for the new function.  Using [.new](http://guides.rubyonrails.org/active_record_basics.html#create), as I understand it, creates a new instance without saving it to the database, like you would build a car without registering it with the police.

Note: railsguides are much better than (ActiveRecord/Base)[http://api.rubyonrails.org/classes/ActiveRecord/Base.html] documentation.
Tested four ways to initialize values when creating a new instance

As the [RailsGuides docs state,](http://guides.rubyonrails.org/active_record_basics.html#create) There are four ways to pass in parameters when you build a new object.

Let's talk about initializing parameters after the fact. Let's say you are building a house.  You can build the house. To finish the house, you need to bolt numbers on the sides of the buildings and ask the person who is about to move in what colors they want to paint it.  That is nice to know, but that information does not affect the pouring of the foundation and building the walls, so you can go head and do that. After that, the new homeowner can bolt on the letters and paint the walls herself.  That's what you are doing when you initialize parameters after the fact.

Now, let's talk about passing in parameters with a hash. In our house analogy, it would be like giving a builders a bag with the numbers inside and a bucket of paint. They can then go ahead and finish up the house for you. The hash is just a convenient way, the bag, to give the builders the nubmers and the paint. The hash is just one thing, whereas if you had to pass in the paint and the numbers individually, it would be like five things.

The thing is, you don't actually have to say that you're giving the builders a bag of stuff, because if you use the right notation, the bag is assumed. Thats why I can skip the curly braces.

Now, let's talk about passing in parameters with a block. I have no good analogy for that. I just know it works, although I don't know why you would use it.
Added a test to test bcrypt's password function in User

You know how some people store their passwords on a sticky note by their computer?  That's the equivalent of storing a password unencrypted in a database.  Anyone who can read it can get into the database.

Bcrypt is like taking that sticky and writing "You shall not pass!" on it when your password is Balrog. It doesn't store the password, it just stores something coded so that only you can get into the password.

Things I knew but forgot I knew: Include is for modules.  Bcrypt is a module.  If a class is a blueprint, a module is a bunch of standard tools that it would be convienent for the person living in the house. They're like appliences and furniture, sort of like stoves and refrigerators, or better yet, a mixer. Not everybody needs a mixer, but you can definitely mix-in a mixer in the houses that need one.

So bcrypt is a collection of things it would be really useful for our User to have. Specifically, it would be really convenient to not stick the password on a sticky. Instead, we ought to encoude the sticky.

See .question #1 in questions file for more questions about bcrypt.
Added a test to see if User.authenticate works

And it does.

Notes: User.authenticate is a class method, which makes sense, because we are trying to find out if a user exists in the database, and if so, if the password matches the things in the database.

A class method is like...lets see, if a class is the blueprints for a house, a class method is like the building inspector tasked with going around to all of the houses and seeing that they are built according to the blueprints.  A class method deals with every object ever created from those blueprints.
Tested user password accessor.

This method gave me a lot of trouble, because I was interpreting something that was actually a method as if it were a variable.

See question 2 in .questions
Added more descriptive test section

Added line four to say I was testing ruby methods.
Also reindented everything.
removed survey_spec.rb

So that I have a cleaner git history. It shall reappaer when I am done testing user validations.
Added test to test activerecord username validation
Added User password validation test

Added a test to see if the user gave a password that was at least six characters long.

Leassons learned: activerecord gives this fascinating...I'm not sure if it's a method or parameter. But it's called errors. So when activerecord is not successful in sticking something in the database, it still keeps the ruby object around, and fills it full of error messages so that a programmer has a fighting chance of figuring out what is wrong.  Activerecord errors is like an english teacher sending back a paper full of red ink and instructions to do it over.
Added a test to see if username was unique.

Note:  Ruby validations are like the doorman to a school.  They prevent the wrong sort of data from getting in. You can hire and fire a new doorman at need, like the way that ruby validations are easily changed.  If you know the back door, you can get in past the doorman and steal a ton of valuable electronics.

Database constraints are like giant steal doors everywhere. More secure, and very hard to change.
Found out that password has test is broken

The hash resets to a different value every time you reseed the database. Wonder why that is?
Tested the activerecord associations for User

Added two tests.  A user has many participants and a user has many surveys through participating in them.

The associations work.  I have a funny feeling that user.surveys ought to be the surveys they have created, not the surveys they have participated in.
Added survey_spec file in specs

Repeating the tests for the survey_spec file.
Tested User-Surveys one to many association.

Found a bug. The User-Survey one-to-many association was not connected because the the column name was named users and not user in the database.

I deciced to 'fix' this by telling Activerecord, "You know that thing called a foreign key, the one you expected to be named 'user_id?' It's actually named users_id."  Activerecord relationships are a lot like actual relationships.  They don't work unless both people know that thye are in a relationship.  So I had to tell both the user and the survey models that they were connected, and they were connected with a key called users_id.
Wrote a test for Survey has many participants relation

It works. Yay.
Tested Survey has many questions association

Wrote a test. Ran it. The survey has many quesions.
Added a test to check through Survey User one to many association

Test is not working. The association is not working. I don't know why. I xed it out so that it becomes pending.
Added test: participant belongs to user

And it works.