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

We should participate in adopt py.test month #317

Closed
vladistan opened this Issue Mar 4, 2015 · 8 comments

Comments

Projects
None yet
4 participants
@vladistan
Contributor

vladistan commented Mar 4, 2015

Py.test is next generation of testing framework for Python. Their community is offering help to other open source projects during April. I think we should participate. All you need is to sign up here http://pytest.org/latest/adopt.html (look down at the projects sign-up link). We will get a volunteer who will help us during the moth of April for about 2/4 hours a week.

I think it is most appropriate for the project owner to sign up.

@rbrito

This comment has been minimized.

Show comment
Hide comment
@rbrito

rbrito Mar 20, 2015

Member

@vladistan, thanks for the hint.

It will be a great opportunity to learn more profoundly how py.test differs from nose (which is what I chose to use, mostly mimic'ing what youtube-dl uses).

If anybody wants to join me in this task, that would be awesome. (BTW, we fail some of the requirements that they have in their list, as I have never made a release; @FedericoCeratto was asking me to make one and this may be an opportunity to actually get it done).

Member

rbrito commented Mar 20, 2015

@vladistan, thanks for the hint.

It will be a great opportunity to learn more profoundly how py.test differs from nose (which is what I chose to use, mostly mimic'ing what youtube-dl uses).

If anybody wants to join me in this task, that would be awesome. (BTW, we fail some of the requirements that they have in their list, as I have never made a release; @FedericoCeratto was asking me to make one and this may be an opportunity to actually get it done).

@FedericoCeratto

This comment has been minimized.

Show comment
Hide comment
@FedericoCeratto

FedericoCeratto Mar 20, 2015

Contributor

+1 for py.test adoption, its fixtures are an awesome feature. Converting the existing tests to py.test should be relatively simple. However, I have to say that simply switching to py.test will not provide huge benefits unless there's a plan to grow the number and complexity of the tests.

Contributor

FedericoCeratto commented Mar 20, 2015

+1 for py.test adoption, its fixtures are an awesome feature. Converting the existing tests to py.test should be relatively simple. However, I have to say that simply switching to py.test will not provide huge benefits unless there's a plan to grow the number and complexity of the tests.

@rbrito

This comment has been minimized.

Show comment
Hide comment
@rbrito

rbrito Mar 20, 2015

Member

I hope to have more test coverage. And the complexity of the tests are simply limited by my (almost non-existent) understanding of testing methodologies and what is possible (and the generous pull requests from other people).

I think that if I learn more about tests, I may create a better test suite (e.g., tests for the currently commited support for ondemand courses).

Member

rbrito commented Mar 20, 2015

I hope to have more test coverage. And the complexity of the tests are simply limited by my (almost non-existent) understanding of testing methodologies and what is possible (and the generous pull requests from other people).

I think that if I learn more about tests, I may create a better test suite (e.g., tests for the currently commited support for ondemand courses).

@FedericoCeratto

This comment has been minimized.

Show comment
Hide comment
@FedericoCeratto

FedericoCeratto Mar 22, 2015

Contributor

I've just noticed that py.test (configured in fabfile.py) runs successfully when code coverage is disabled, and fails UtilsTestCase.test_random_string reproducibly when code coverage is enabled:
py.test --cov coursera
....

      self.assertEqual(res, '0UAqFzWs')

E AssertionError: '0uaQfZwS' != '0UAqFzWs'

Contributor

FedericoCeratto commented Mar 22, 2015

I've just noticed that py.test (configured in fabfile.py) runs successfully when code coverage is disabled, and fails UtilsTestCase.test_random_string reproducibly when code coverage is enabled:
py.test --cov coursera
....

      self.assertEqual(res, '0UAqFzWs')

E AssertionError: '0uaQfZwS' != '0UAqFzWs'

@meejah

This comment has been minimized.

Show comment
Hide comment
@meejah

meejah Apr 8, 2015

Contributor

Hi, I am your py.test volunteer! I sent @rbrito email a couple days ago, but perhaps it went missing?

Let's start by me asking what you most want help with? If you haven't yet, can you read the overview at http://pytest.org I see you already have a "fixtures" directory with (what I'm guessing is) data for your tests. When reading pytest.org, concentrate on what py.test's notion of a "fixture" is.

I have a little demo-project that shows how (I would) set up py.test with a few others tools, including distutils/setup.py stuff:

https://github.com/meejah/python-skeleton

Additional to py.test help, I could help you get a setup.py and a release to PyPI going. From your side, you'll need to get an account on PyPI if you don't already have one.

Contributor

meejah commented Apr 8, 2015

Hi, I am your py.test volunteer! I sent @rbrito email a couple days ago, but perhaps it went missing?

Let's start by me asking what you most want help with? If you haven't yet, can you read the overview at http://pytest.org I see you already have a "fixtures" directory with (what I'm guessing is) data for your tests. When reading pytest.org, concentrate on what py.test's notion of a "fixture" is.

I have a little demo-project that shows how (I would) set up py.test with a few others tools, including distutils/setup.py stuff:

https://github.com/meejah/python-skeleton

Additional to py.test help, I could help you get a setup.py and a release to PyPI going. From your side, you'll need to get an account on PyPI if you don't already have one.

@meejah

This comment has been minimized.

Show comment
Hide comment
@meejah

meejah Apr 11, 2015

Contributor

Can someone from this project please contact me if you're still interested in py.test month? I'm also usually on OFTC if IRC is easier, or email is fine too.

Contributor

meejah commented Apr 11, 2015

Can someone from this project please contact me if you're still interested in py.test month? I'm also usually on OFTC if IRC is easier, or email is fine too.

@FedericoCeratto

This comment has been minimized.

Show comment
Hide comment
@FedericoCeratto

FedericoCeratto Apr 11, 2015

Contributor

Published PR #334 to switch to py.test.

Contributor

FedericoCeratto commented Apr 11, 2015

Published PR #334 to switch to py.test.

@rbrito

This comment has been minimized.

Show comment
Hide comment
@rbrito

rbrito May 16, 2015

Member

Hi.

First of all, I would like to thank @vladistan for making me aware of the
project, @FedericoCeratto for pushing me to adopt pytest and @meejah for
being so kind to donate a portion of his time to help with the adoption of
pytest.

I must say that I feel that, even though our testing is far from perfect (I
still don't know how to properly test things like network connections, which
is something that has been plaguing the project right now with SSL errors
and differences across platforms and the changing pace of cryptography in
the world), I now know a bit more about pytest and I think that I can
refactor our existing tests a bit more so that they become more readable and
maintainable.

As I have already sent the required form about the participation of the
project in pytest's "Adopt Pytest Month" program, I think that we can close
this bug now.

Once again, I would like to thank everybody involved in this for making our
project better and I hope that you can find some time to help me help our
users.

Being the sole maintainer right now is sucking a lot of time and I could
sincerely use a little help from people more experienced with me with
Python, testing and anything at all.

Thanks to you all,

Rogério Brito.

Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Member

rbrito commented May 16, 2015

Hi.

First of all, I would like to thank @vladistan for making me aware of the
project, @FedericoCeratto for pushing me to adopt pytest and @meejah for
being so kind to donate a portion of his time to help with the adoption of
pytest.

I must say that I feel that, even though our testing is far from perfect (I
still don't know how to properly test things like network connections, which
is something that has been plaguing the project right now with SSL errors
and differences across platforms and the changing pace of cryptography in
the world), I now know a bit more about pytest and I think that I can
refactor our existing tests a bit more so that they become more readable and
maintainable.

As I have already sent the required form about the participation of the
project in pytest's "Adopt Pytest Month" program, I think that we can close
this bug now.

Once again, I would like to thank everybody involved in this for making our
project better and I hope that you can find some time to help me help our
users.

Being the sole maintainer right now is sucking a lot of time and I could
sincerely use a little help from people more experienced with me with
Python, testing and anything at all.

Thanks to you all,

Rogério Brito.

Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

@rbrito rbrito closed this May 16, 2015

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