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

use pytest (bug 1090184) #369

Merged
merged 1 commit into from Dec 9, 2014

Conversation

Projects
None yet
3 participants
@magopian
Contributor

magopian commented Nov 19, 2014

This builds on top of #366 (which got rid of test_utils), and adds pytest (which is awesome).

Fixes bug 1090184

@davidbgk

This comment has been minimized.

Show comment
Hide comment
@davidbgk
Member

davidbgk commented Nov 20, 2014

Mindblown.

@davidbgk

This comment has been minimized.

Show comment
Hide comment
@davidbgk

davidbgk Nov 26, 2014

Member

Impressive work, especially on the ES tests! r+ci

Member

davidbgk commented Nov 26, 2014

Impressive work, especially on the ES tests! r+ci

# Monkeypatch settings.LESS_BIN to not call the less compiler. We don't
# need nor want it in tests.
monkeypatch.setattr(settings, 'LESS_BIN', 'ls')

This comment has been minimized.

@davidbgk

davidbgk Nov 28, 2014

Member

Just curious, why ls?

@davidbgk

davidbgk Nov 28, 2014

Member

Just curious, why ls?

This comment has been minimized.

@magopian

magopian Nov 28, 2014

Contributor

The real less compiler returns the name of the resulting file (which will then be added inline in the html). With ls, we also have the name of a file (the less file), which will thus be added inline in the html. We're lucky that the tests are actually grepping on a css rule that doesn't change once compiled!

@magopian

magopian Nov 28, 2014

Contributor

The real less compiler returns the name of the resulting file (which will then be added inline in the html). With ls, we also have the name of a file (the less file), which will thus be added inline in the html. We're lucky that the tests are actually grepping on a css rule that doesn't change once compiled!

@@ -697,7 +697,7 @@ def render_csv(request, addon, stats, fields,
writer.writeheader()
writer.writerows(stats)
fudge_headers(response, list)
fudge_headers(response, stats)

This comment has been minimized.

@davidbgk

davidbgk Nov 28, 2014

Member

👍

@davidbgk
@robhudson

This comment has been minimized.

Show comment
Hide comment
@robhudson

robhudson Nov 29, 2014

Member

I was expecting a lot more changes.

I haven't followed along much but why is pytest better? Should zamboni follow this change also?

Member

robhudson commented Nov 29, 2014

I was expecting a lot more changes.

I haven't followed along much but why is pytest better? Should zamboni follow this change also?

@magopian

This comment has been minimized.

Show comment
Hide comment
@magopian

magopian Nov 29, 2014

Contributor

Hello @robhudson, I answered by email ;)

The TL;DR is:

  • pytest can run nose tests, so the changes aren't that big (most of the changes are "because" of tox and its random HASHSEED
  • pytest is better for many many many reasons (see the email, or the documentation)
  • I recommend that zamboni follow this change, but we have a saying in France "les conseilleurs ne sont pas les payeurs": advisors aren't those who pay.

It did take quite some time to find all the changes needed, and the round trip didn't help (each test run used to take over 50minutes before the split in travis).
I find pytest vastly superior, but it does have a cost attached, mainly for its longer run (because it's missing the fixture bundling feature atm, and because it does have a (small) learning curve). Even if "high profile" django devs are using it, Pytest is less widespread, so there's a bigger chance a new developer already knows nose/unittest.

On the other hand, using pytest is really pythonic: simple assert statements instead of the dozen of self.assert*, or nose helpers (like eq_ or ok_).

If you plan on switching Zamboni to pytest, I'd be delighted to help!

Contributor

magopian commented Nov 29, 2014

Hello @robhudson, I answered by email ;)

The TL;DR is:

  • pytest can run nose tests, so the changes aren't that big (most of the changes are "because" of tox and its random HASHSEED
  • pytest is better for many many many reasons (see the email, or the documentation)
  • I recommend that zamboni follow this change, but we have a saying in France "les conseilleurs ne sont pas les payeurs": advisors aren't those who pay.

It did take quite some time to find all the changes needed, and the round trip didn't help (each test run used to take over 50minutes before the split in travis).
I find pytest vastly superior, but it does have a cost attached, mainly for its longer run (because it's missing the fixture bundling feature atm, and because it does have a (small) learning curve). Even if "high profile" django devs are using it, Pytest is less widespread, so there's a bigger chance a new developer already knows nose/unittest.

On the other hand, using pytest is really pythonic: simple assert statements instead of the dozen of self.assert*, or nose helpers (like eq_ or ok_).

If you plan on switching Zamboni to pytest, I'd be delighted to help!

magopian added a commit that referenced this pull request Dec 9, 2014

@magopian magopian merged commit 1028883 into mozilla:master Dec 9, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@magopian magopian deleted the magopian:1090184-use-pytest branch Dec 9, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment