Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tidy tests #22

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Tidy tests #22

wants to merge 9 commits into from

Conversation

joncotton
Copy link
Member

This is a better, cleaner version of this attempted PR #18.

It removes unused imports. It orders them in what I think is a cleaner way (you can tell me to stop this if you just think it's horrible). I found some new things too.

  • TestCase now uses ArmstrongTestCase instead of DjangoTestCase
  • TestCase did setUp() that was only used in SimpleWellViewTest so I moved those tasks over
  • I removed an unnecessary parent test case
  • I found an orphan sanity check

It's meant as an extension to PR #20. So the actual diff is simpler. Here's the diff between those two.

- make it use the base ArmstrongTestCase
- move the setUp() and assertInContext() methods out of the base class and into the class they are used in
- remove an unnecessary WellViewTestCase class
def default_kwargs(self):
return {
"template_name": "index.html",
"well_title": self.well.title,
}

def assertInContext(self, var_name, other, template_or_context):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's best to keep assert* methods like this outside of the test classes they're used. Invariably, you end up wanting to use them elsewhere if they're useful. If this is to be moved anywhere, it should be in to armstrong.dev so the method is available everywhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now should I move it back into _utils.py.TestCase?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's one option, or if you'd like to move this into armstrong.dev entirely that's a good option as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR #9

@tswicegood
Copy link
Contributor

The requirements/dev.txt file needs to be updated now to ensure that armstrong.dev>=1.11.0 is installed. Once that's done, I think we're set.

@joncotton
Copy link
Member Author

halp! Not quite ready. Version conflicts. I'll update requirements.base.
requirements/base.txt has django-reversion==1.3.3
package.json has "django-reversion==1.4.0"

`armstrong.dev` now has the `assertInContext` method.
`django-reversion` should be at 1.4, same as the package.json file and same as armstrong.core.arm_context
@joncotton
Copy link
Member Author

@tswicegood _before you merge_ This includes/builds-off the additional test added in this original PR #20. Merge that one first and this PR will get a little simpler.

def test_raises_NotImplementedError_on_exclude(self):
def test_raises_NotImplementedError_on_all_and_exclude(self):
merge_qs = MergeQuerySet(self.qs_a, self.qs_b)
with self.assertRaises(NotImplementedError):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please break these out into multiple test methods? If this assertRaises failed, we wouldn't know that the next assertRaises also fails (or passes) until we fixed the first method. It's generally a good rule to keep one assertion per test method -- or at least one concern. Here, all() and exclude() are two different completely different methods that just happen to raise the same error.

@@ -1,3 +1,3 @@
django>=1.3
django-reversion==1.3.3
django-reversion==1.4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better change. Let's nix this file entirely and update requirements/dev.txt to not include it.

add_n_random_images_to_well,
generate_random_image,
generate_random_story,
generate_random_well)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer the previous style here, but whatever.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto. I've reverted some of these in joncotton#1 to keep it consistent with imports elsewhere. They should really either be one import, one line; or multi-line imports with () like this was originally.

@niran
Copy link
Contributor

niran commented Mar 19, 2012

This looks ready to go. There are a lot of different things going on in this PR that were hard to isolate. A PR for adding missing tests (like #22 was, but removed from this one), one for PEP 8 fixes, and one for code clarification would've been easier to sign off on.

@joncotton
Copy link
Member Author

Well #20 was a separate PR just adding the tests. It didn't get merged by the time I wrote this.

@tswicegood
Copy link
Contributor

@joncotton sorry that didn't get merged in before this started. It's best to start all of your feature branches off of master, however. That way you don't have to clean out parts of the PR if the other code doesn't get merged for some reason. Of course, there is an exception to the rule. If one PR builds off of code that's in a previous one, starting from that point is what you have to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants