Test creating an overheard with a form

Again we see the pattern of imaging the user interface, then codifying
it into a test. To get started, I
[copy-pastad](http://imgbit.com/images/652a2231491269586521.jpg) the
test/features/list_overheards_test.rb and renamed the test class and
test method.

New Methods
===========

`click_on` - Find and clicks a button or link.  Provided by
`Capybara::DSL`.
[Reference](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions:click_link_or_button)

`fill_in` - Find a field and fill in a form field. Field must be labeled
with the text of the first argument.  Fills in the field with the
`:with` keys value from the options hash.  Provided by `Capybara::DSL`.
[Reference](http://rubydoc.info/github/jnicklas/capybara/master/Capybara/Node/Actions#fill_in-instance_method)
Create link to page where we create new overheards

The pattern we're following is that first, we declare our intent; then
we make the change.

We used the test to declare the intent that their would be a link with
the text "Add Overheard".

We now use the link to declare the intent that the application will have
a
[route](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary#route-sinatra)
that responds to GET requests to the path `/overheards/new`.

As our tests run, we see the failure message has changed. Instead of saying
'Unable to find link or button "Add Overheard"' it now says 'Unable to
find field "Body"'.

This is good! It means our test successfully clicked on the Add
Overheard link and tried to take the next step in the test; filling in
the text field.

New Tags
========
`nav` - Contains navigation elements.
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nav)

`a` - Stands for 'anchor'. Creates a
[hyperlink](https://https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary/#link-html)
to another page.
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a)
Create new overheards form and route to show form

Here we're creating two things:

1. A route that builds responses to GET requests to "/overheards/new".
   (This may look familiar, as its the `href` attribute of the "Add
   Overheard" link in the previous commit.)
2. A form that sends a POST request with its data to '/overheards'.

New Concepts
============

Organizing Routes
-----------------

Think of a web application as a directory structure. Our web app has a
folder named `overheards` with a file named `new`. The `new` file is an
html form to collect data used to make an overheard.

Web Forms
---------

[Web
forms](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary/#form-web)
collect input from a user. When a form is "submitted" the browser
requests the url defined in the forms action attribute with the verb
defined in the forms method attribute. It sends all of the data from the
forms input fields as part of the request.

Here `<form method="POST" action="/overheards">` tells the browser to
request the directory `/overheards` via POST while sending all of the
user input in the request body.

The input is sent as key-value pairs; where the name of the input field
is the key and what the user entered is the value. If someone had put
"Hi" in the field and submitted the form, the HTTP request looks
something like this:

```
POST /overheards
Content-Type: application/x-www-form-urlencoded

overheard[name]=Hi
```

New Elements
============
`<form>` - Contains input elements. Creates an interactive [web
form](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary#form-web).
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form)

`<label>` - Creates a clickable word or phrase which focuses the browser
on a input element. May contain an [input
element](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary#input-field-html).
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label)

`<textarea>` - An input field that takes a long block of text.
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea)

`<button>` - A clickable button which submits the form that contains it.
[Reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button)
Create overheard in database on form submission

BEHOLD! We now are storing overheards in the database! These 4 lines are
the heart and soul of our program:

1. We define a
[route](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary#route-sinatra)
that builds responses for POST requests to /overheards.
2. When a request comes in, we get the request data from
params["overheard"]. If we `p params` It will look something like `{
  "body" => "Whatever the user wrote" }`
3. We pass that data to the `Overheard.create` method that
`Datamapper::Model` so generously provides.
4. We send a response to the browser to `redirect` it to the "/" route.

New Methods
===========

`post` - Define a route that builds responses to POST requests.

`redirect` - Sends a response to the requester with the [301 status
code](http://en.wikipedia.org/wiki/HTTP_301) and a location of the
passed in string. Causes a whole-nother [request response
cycle](https://github.com/codeunion/fundamentals-of-web-development/wiki/Glossary#requestresponse-cycle)

`Datamapper::Model#create` - Creates a row in the models table with the
attributes passed in. Returns an instance of the model.
[Reference](http://rdoc.info/github/datamapper/dm-core/DataMapper/Model#create-instance_method)
Extract default layout

Because the two views were pretty much the exact same, it's a perfect
opportunity to extract a layout. Now we only have to change
`views/layout.erb` if we make any layout changes.

The secret sauce of a layout is calling `yield` within the template.
This is how you tell erb to render the template specified within the
route.

New Syntax
==========
`<%= foo %>` - This `erb` syntax says to evaluate the code between `<%=`
and `%>` as ruby and print out the result.
Extract FeatureTest

The two feature tests were also very very similar; so I wrote a very
tiny ruby file that:

1. Requires the other files a feature test needs to run
2. Creates a custom type of test called a FeatureTest that extends
   `MiniTest::Test` and includes the `Capybara::DSL` and
   `Capybara::Assertions`

New Methods
===========

`require_relative` - looks for the given file located relative to the
current filei and requires it.
Test creating an invalid overheard

Our test trys to create an overheard without a body. In this case, we
want our user to stay on the same page and see a nice error message.

Unfortunately, it looks like we redirect to "/" even if the user
doesn't provide a body. How sad!
Add validation that Overheard must have a body

Here we're doing two things:
1. We're creating a validation that will prevent an overheard from being
   created if a body isn't provided
2. We're only redirecting if the creation was successful; otherwise we
   re-render the new overheard form
Display overheard body error to the user

Bam! We've got errors being shown to the user. Important things to
consider:

1. `views` have access to `@instance_variables` defined in routes. This
   means we can access the `@overheard` variable inside of our
   `new_overheard.erb` view.
2. Every `Datamapper::Model` has an `errors` method that contains
   validation errors that were caught when trying to create or validate
   the model.
3. I had to update the assertion that tested for the error because I
   used the wrong words. Even though the page was showing the error, it
   didn't exactly match what I expected.

New Methods
===========

`Datamapper::Model#errors` - Provides a hash of errors caught when
validating a model. Each property of the model is a key in the errors
hash, and an array of validation failures is the value. If there are no
validation errors for an attribute, it returns an empty array.
Merge pull request #8 from codeunion/2-user-may-create-overheard-via-form

User may create overheard via form