Prepare for a more organized set of tests.
New stub file for view tests.
Turns out we don't need the __init__ code here.

The Django framework apparently automatically discovers all the tests in
the tests/ subdirectory.
Basic authentication testing.

Also include some fuzz testing with random byte sequences that should
all fail.

Also (re)learned that User( 'email', 'username', 'password' ) does
nothing to the password.  This means that the password is unusable
through the standard Django authentication schemes, because it is not
properly salted and hashed.  Fix by instead using
User.objects.create_user, which makes the password "usable".
User.objects.create_user preferred over User().save()

Per same logic as referenced in parent commit.
Prefer reverse() over hard-coded URLs.

Basically, use of reverse increases flexibility, especially since I was
never sold on the URL scheme to begin with.  With this, urls.py can
remain the single-point-of-authority.
Test that unauthenticated users cannot create analyses.
Add logout test.

Also, add backup test to ensure that the test-runner thinks we're
authenticated as well, not just that we get back the expected cookie
from the server.
Update test docstring
Comment update; properly check server returns
Mimic Django's style.

Django 1.6 added the ability to create the response we want, so this
particular section needs to be refactored.  Until then, however, just
mimic Django's ALL CAPS style for the reason-phrase.
Bug fix, discovered by soon-to-be-committed test.

Creating an analysis worked in that it created the new analysis, but the
UI was not informed of such.  This occurred because the HTTP request to
create the analysis was @require_POST wrapped, but it outsourced to a
@require_GET wrapped function.  As those two are mutually exclusive, the
error.

Hooray for functional API testing, not just unit testing.
Bug quashed: control characters in analysis names.

Bug quashed thanks to soon-to-be-committed new test.

An unlikely situation, but nevertheless should remove bad characters.
I'd like a whitelist, rather than a blacklist, but I don't currently
know what that whitelist would be.
Analysis creation test.

Thanks to this test, at least one real UI bug is fixed (new analysis
data showing up without having to reload the page), as well as some more
robust data validation.

With this test, we have at least one set of functional tests from which
others can scaffold.
Quash data return bug.

The next iteration of tests (soon to be committed) found another bug:
when updating analysis meta information, TemoaDB was not reporting back
the new results.  With this commit, it does.
Quash test-identified bug.

If the user attempted to change name of analysis to one that already
existed, rather than a helpful error message, the UI would just
unhelpfully say "500 - The server encountered ...".  Which is true -- an
unhandled exception had occurred.  The fix: handle the exception
appropriately as a user error.
Squash test-identified bug.

Period_0 and Vintages go hand in hand.  Period_0 should not be empty,
and period_0 must be a member of the analysis vintages.  However,
because the analysis must be created first, Period_0 cannot be a foreign
key into the Vintages table.  Thus, this needs to be checked by the
application code, which I forgot to write, initially.  Done.
Test-framework enabled more helpful error messages.

This is not a normal use-case a user would run into, but for
completeness, the framework now returns a helpful message if one tries
to modify a non-existent analysis, or one not owned by their user.
Test update analysis.

This is a non-exhaustive set of tests (functional testing is
/difficult/), but has uncovered a few bugs already.  This only covers
updating an analysis, basically through /analysis/<id>/update, but I'm
very pleased to have a test framework now.  The structure is now in
place, with examples, for future work in this area.