Can you add a docstring at the top of the file? Just a one-line summary. Unit tests for <full class path>. is good.

There's a particular order that imports need to be grouped in (blank lines separating them):

Python-provided modules
Third-party modules (from the perspective of the project you're working with)
Project's own modules

And these must all be in alphabetical order. Skip any groups that don't have modules.
So in your case, the django ones would be in its own group at the top, then a blank line, then the djblets ones. Alphabetical.

Mind naming this request_factory? We try to avoid abbreviations, since it's harder to search for them, and isn't self-descriptive.

Let's rename this to just form. class_under_test isn't actually very self-describing.

This will be a lot easier to read and maintain (and fit under 79 characters) as:

self.form = IntegrationConfigForm(
    integration=self.integration,
    request=self.request,
    instance=None,
    data={
        'enabled': True,
        'name': self.mock_name,
    })


Note also the keyword arguments. Being explicit here is really good when there's a lot of arguments going on.
Also also, note the self.mock_name. No need to reference the class name directly.
I think we're only using that name once, so we can probably even nuke the class attribute.

These docstrings are shown when running the test suite, and since there's usually so many (thousands in Review Board!), it's very important that they're explicit. They should always include the thing being tested. So you'd probably want something like:

"""Testing IntegrationConfigForm.config returns the configuration instance"""


Or IntegrationConfigForm.get_key_value() below, etc.

Rather than testing whether this returns a value, how about testing that it's the exact value we're expecting?

It's confusing that there's two name for this... We try to stick with the singular form, assertEqual. (We don't always get it right -- there's a few stragglers in the codebase.)

We never want to use the u prefix on any strings. We get those automatically from the from __future__ import unicode_literals at the top on Python 2.x, and it's the default for 3.x.

Just a few style-related comments:

Please add the bug number to the "Bugs" field on the review request.

Please move the last part of your description (about tests passing) to the "Testing Done" field. That also needs a period.

Please add a class docstring for this (can be the same as your module docstring).

This line should have a comma at the end.

This is coming along nicely! I have a few suggestions on docstrings, to help make them more self-descriptive.

Missing a period at the end of this.

This is missing a period at the end.

Super minor nit, but it's common to have a blank line after the super() call. Helps to think of code like paragraphs. One paragraph is "We're calling the parent method and setting up all of its state." Next paragraph is "We're setting up the basic objects needed to work with integrations." Paragraph after is "We're setting up state for the form."

I think the docstrings here aren't really descriptive enough. I'm having trouble understanding from them what we're testing.
The first test says it's testing a default field, but the first thing we check is actually a value provided to the form (form data filled in by a user and POSTed to the page). I think this is really testing that "get_key_value() returns values from form data"
The second, I don't think "default field" makes any sense in the context. I think it's more that "set_key_value() overrides form data"?
The third is more correct but maybe vague? How about "set_key_value() sets custom non-field data"?

This looks good to me. Thanks, Monica!

Juuuust about there!

The lines in the description should wrap at 79 columns. Currently the first is 87 columns.
As a tip, you'll usually get a column limit when composing a Git commit in your editor, helping to stay under this limit. If you modify the commit after the review request is posted, you can update the information on the review request from the commit by passing -g yes when running your rbt post -u.

Oh, just realized. You'll want assertIsInstance here. It's a nice alternative, because if the test fails, it'll provide more useful information about the types.

Looks like this is wrapping too early. It should be closer to 79 characters.
Same with the ones below.

Ship It!