Install RSpec for automated testing

I need some automated tests to support me in refactoring.  The Rails
default Test::Unit tests are currently in place, but I'm more familiar
with rspec, and no effort has been invested in Test::Unit yet.  Also,
I like how rspec can output documentation of coverage (specdoc) that
reads like English.

Make the following changes:

* Remove test/
* Add rspec-rails to Gemfile
* Run bundle install
* Run rails generate rspec:install, which adds .rspec and
  spec/spec_helper.rb
Install Capybara gem for automated integration testing

My first tests will be end-to-end tests.  Unfortunately Rails
integration tests make it hard to test forms: it allows you to
accidentally "submit" a form with fields that don't exist.  Capybara
addresses that problem, testing the form itself and the form action in
one step.

Install and configure Capybara.
Add feeder spec and fix HTML nesting and

constructor

I want a test for the FeederController so I can refactor.

Add a failing test for the feed action, and then make it pass:

* Inject SerialPort mock to isolate test from real Serial port to
  fix exception on serial port access
* Fix indentation of application layout so that head and body are
  nested within the top-level html tag to fix HTML parsing error
* Call super in the FeederController's initialize method so that the
  application layout is used, which allows the test to use the "Fed!"
  flash as an indication of test success
Add passing specs for #starve and #dose actions for completeness

We have a spec for #feed, but not complete coverage yet.

Add specs for the remaining actions so we have complete coverage.
Move Pump model to its own file

The Pump model is currently living right in the FeederController file.
This is a bit awkward because it clutters the FeederController file.
Down the road, if the pump is used in another file, it'll also make it
hard to autoload the Pump model.

Move the Pump model to app/models.  Even though it does not use
ActiveRecord, it is definitely part of the model layer.
Create a SimpleSerialPort wrapper for SerialPort

I need to mock this boundary of the application.  Best practice says that
I should only mock APIs owned by the application.  Also, the interface of a
SerialPort is far too complex to faithfully mock.

Wrap this vendor library with an interface owned by the application, one
which is far simpler.
Allow the SimpleSerialPort spec to run without

booting Rails

Rails takes a long while to boot up -- serveral seconds -- and it will
take even longer once we have more gems and plugins installed.
Sometimes I run specs a few times per minute when I'm developing.
That Rails boot time can really add up.  Usually I'm just running one
example, or one spec file, so the specs themselves don't take very
long, and the Rails boot time dominates.

Use a separate spec helper file for unit tests that don't need to load
all of Rails.  This is a bit experimental.  It's an approach advocated
by folks like Corey Haines.  It cuts runtime of a single example by
about 75% right now.
Remove serial port details from Pump model

The rest of the application shouldn't be required to know about the
details of a SerialPort when it deals with a Pump.  Also, the pump
should use our new SimpleSerialPort wrapper for SerialPort.

Switch to the narrower SimpleSerialPort interface, and stop passing
the path of the serial port from the FeederController.  This means
FeederController is now completely decoupled from serial ports, and
the Pump model is better focussed on its responsibility: controlling a
pump.
Make the serial port wrapper class configurable

I'd like to avoid talking to a serial port on my Mac in development
mode; it's not really hooked up to an Arduino.  So I need the serial
port to be configurable to be a stub.

Also, it's best if the Pump class knows just a bit less about the
default serial port.

Inject the configuration from the controller, because that already
knows about Rails, and it seems acceptable for it to know that a
hardware configuation exists (though not that it's necessarily
serial-specific).  Relieve the Pump model of knowing which class to
instanciate to create a serial port wrapper.
Implement DevSerialPort stub for development

Currently, "rails server" doesn't work unless the application is
connected to a real serial port.  But that's generally not the case
when developing on my Mac.

Provide a stub serial port and wire it up via the hardware config
in development mode only.
Change FeederController to #dose asynchronously

When I dose with a pump, the controller waits for the dose to finish.
As a result, the browser doesn't get a prompt response, leaving the
user in limbo.

Change the dose action to just *start* the dosing in another thread
and return immediately.
Allow multi-cycle dosing at specified amount and interval

The dose action always doses once for five seconds.  An operator needs
more flexibility to maintain a healthy system.

Allow the total quantity (currently in seconds), the number of cycles,
and the pause between them, to be specified as part of the dose form.
Track db/schema.rb

Rails projects should track db/schema.rb when the database is used.
We haven't needed the database so far, but we're about to.  It'll be
nice to have a clean diff of the added schema, so start with an
empty schema.rb file, as generated by rake db:migrate.
Record each dose to reveal whether one is in progress

We currently have no way to display the current status of any doses
that have been initiated.

Store a dose when it is requested, and mark it complete when it
finishes.
Show a list of past doses on the feeder index page

We store doses as they are requested, but there is no way to see a
record of what's been recently requested, and, in particular,
what's currently in progress.

Add a list of past doses to the index page, marked up with bootstrap
CSS classes.
Extract feeder#dose to a Doser method object

The dose action is a bit complicated for a controller action.

Refactor it by extracting to its own object which can manage the dosing
process.  Break apart the method into helpers so that each helper method
is brief, focussed, and at a single level of abstraction.

Split the asynchronisity into a separate API entry point to facilitate
testing within a single transaction.  (Transactional fixtures are
incompatible with multithreaded tests.)
Add a simple spec to Dose to replace pending placeholder
Remove Doser's dependency on a Rails environment

Doser requires a full rails environment for testing because it
creates a Dose ActiveRecord model.

Pass in the active record class as a factory object.  This flex
point allows a mock to be easily injected during testing.  This
in turn allows the spec to run without loading Rails and without
hitting the database.  It also improves code quality by reducing
coupling between the Doser and Rails.
Reduce sleep times in Doser spec

Now that the Doser spec runs without ActiveRecord, the length of
sleep time has become the limiting factor on runtime.

Reduce all the timings by 10x for a 5x reduction in spec runtime.
Move non-transactional examples to their own describe block

We're currently running all the feeder specs without transactional
fixtures, even though it needn't be that way.  Also, we're repeating the
Dose.destory_all cleanup.

Create a nested describe block to limit scope of disabled transactional
fixtures move destroy_all to a before block.