Thanks for the change!
I have a handful of comments here, which really focuses on a few key areas:

Getting things in shape for our documentation, coding, and unit test conventions.
Best practices for working with kgb and spies.
A better approach for how to test views.

The end result will be a file that's probably half the size :) Come talk to me if you have any questions!

Docstring summaries must always begin on the """ line. If the docstring is single-line, the trailing """ should also be on the same line.
You'll want to go through our Writing Python Docs guide and make sure all your docstrings follow the standards we list there.

The very first import on any module needs to be:

from __future__ import unicode_literals


This turns on Unicode strings on Python 2.x, which ensures that 2.x and 3.x will work the same way.
There must be a blank line between this and any other imports.

Two important things:

There must be only a single blank line between groups.
Imports must always be alphabetical, so it's clear where we should put new imports. This applies to the from ... part and to the list of things imported (import ...).

Since we support Python 2.x, you'll need to always inherit from something. In this case, object.

Same note as above. This is missing a period, and doesn't really tell us anything about the class.

This is implied in a class, so you shouldn't need it.

Same note about inheritence here.

We have potentially thousands of unit tests running (in Review Board especially), so it's always important that our docstrings contain enough information to help us know what's being tested.
As such, we want to list the class/function/whatever being tested in the docstring, like:

"""Testing register view when ..."""


The test method must also contain information as well, so test_register_with_.... It must also be completely lowercase. So I'd call this test_register_without_post_method.

The way we want to use this is to actually have SpyAgency mixed in to the parent class, like:

class ViewTests(SpyAgency, TestCase):


Then we'd call self.spy_on(...).
This helps take care of some important cleanup tasks.

We try to avoid using call_original=False where possible, because this masks other issues. Let's try without these and see if anything breaks. If something does, it means our test state isn't complete.

It's generally best that we avoid calling views directly. Or mocking a request, for that matter. Instaed, we should take advantage of what Django offers, which is a nice test client that simulates HTTP requests. This ensures that we are working with real-world objects, testing real-world view/response paths.
(Documentation on the test client)
This is done by running code like:

response = self.client.get('/some-url/')

# or

response = self.client.post(
    '/some-url/',
    {
        'key': 'value',
        ...
    })


The latter for specifying form fields/POST data.
You'll set up these URLs by defining a urls attribute to a module you'll need to create alongside this file. See the documentation.
We also want to make sure we're always checking the responses, at a minimum checking the HTTP status code, but also checking whether it redirected to the right place (in this case).

You won't need this once you inherit from SpyAgency.

No blank line here.

A few minor things on the review request itself:

1. Can you add the bug ticket number (4588) to the "Bugs" field of this review request? It'll automatically link to the Splat ticket.

2. Testing info should be listed in "Testing Done", not "Description".

3. Can you wrap your "Description" and "Testing Done" to 80 chars to make it more readable?

Where do the variable values come from? ie. title, form? Are they populated as a result of the request?

Do these functions run before and after every test?

@Hannah& Kat
Yes, they do.

setUp() and tearDown() are optional functions. We can use them to factor out the code common to all tests. 
setUp() runs before each test in the class. tearDown() runs after each test in the class.
Testcases are often used in cooperative multiple inheritance, so we should call super in these methods so the base class's setUp and tearDown methods also get called.

references:

1.(https://riptutorial.com/python/example/13280/test-setup-and-teardown-within-a-unittest-testcase)

Going to make some minor tweaks to this and land it. Thanks!