python-mailsnake
python-mailsnake copied to clipboard
michaelhelmick
Nose tests
I concur. I've always wanted to write tests, just never took time to learn
Mike Helmick @mikehelmick
On Thursday, July 12, 2012 at 2:46 PM, Brad Pitcher wrote:
Regression tests are badly needed
Reply to this email directly or view it on GitHub: https://github.com/michaelhelmick/python-mailsnake/issues/9
FYI - when you include your twitter handle in the signature in github, it's actually tagging my username on github and sending me notifications.
@brad @michaelhelmick So is the plan to test against a 'mailsnake' mailchimp account to test things like filters?
@michaelhelmick But would it be a good idea to use a mailchimp account created for this purpose? Allowing testing of listMembers with status='unsubscribed' ect. or should the tests be able to be run against any apikey?
Tests can run agains an API key. If it's hooked up with travis, we can have secure variables so the API key isn't exposed
Mike Helmick Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, June 29, 2013 at 6:35 PM, Gilbert Bishop-White wrote:
@michaelhelmick (https://github.com/michaelhelmick) But would it be a good idea to use a mailchimp account created for this purpose? Allowing testing of listMembers with status='unsubscribed' ect. or should the tests be able to be run against any apikey?
— Reply to this email directly or view it on GitHub (https://github.com/michaelhelmick/python-mailsnake/issues/9#issuecomment-20238439).
Mhm
Mike Helmick Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, June 29, 2013 at 6:39 PM, Gilbert Bishop-White wrote:
So the tests should be general enough to be run against any apikey?
— Reply to this email directly or view it on GitHub (https://github.com/michaelhelmick/python-mailsnake/issues/9#issuecomment-20238499).
Hello,
If you are open to some feedback I have some thoughts on the tests branch. If you don't want feedback than please just ignore this. I understand that not everyone has time or desire to pursue learning testing best practices.
First of all, if you are going to ship tests with your project and include them in the repo they should be able to be run by anyone who clones the repo. Your import of "from .secret_keys import MAILCHIMP_API_KEY" prevents this from happening. Additionally, you probably don't want to hit the actual mailchimp API servers every time tests are run. As you are probably already aware, the tests you have written are functional tests that test the full system stack in an actual "production like" deployment. These tests are fine to have for your own purposes in your personal build and deployment process but the kind of tests you want to write and include in your open source repository are unit tests as well as functional tests that are isolated just to testing your code base but "mocking" or "stubbing" away an external dependencies.
Unit tests allow people working on your project to test that their changes haven't broken any functionality when they alter the code. Unit tests should be able to be run "out of the box" by anyone who clones your repository. Unit tests should be able to be run anytime, all the time, by a lot of different people meaning you generally don't want to be sending network traffic or hitting live APIs in unit tests. Unit tests can be a bit tricky to write when you are first starting. For a good example of how to write unit tests for a library that actually uses the same API as you are using, I would recommend checking out this project and the tests that the maintainer has written: https://github.com/ericrasmussen/postmonkey/blob/master/postmonkey/tests.py
I commend you for at least beginning the process of writing tests. It's a great first step. However, for this library to be useful to as many people as possible in the open source community you really do need to add some proper unit tests.
It's definitely worth reading up on testing and specifically unit testing if you are going to be active in the open source community. I would highly recommend this book: http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
I've wrote tests for Twython,
https://github.com/ryanmcgrath/twython
I know that testing against the actual live mail chimp API requires a internet connection and might not be the best idea, but this allows us to make sure anything we test against in the actual mail chimp api hasn't changed.
Like if .ping() stopped working, we'd know rather than testing against local fixtures and .ping() always working.
I've changed the whole .secret_keys thing from whoever wrote that to use os environment variable. Along with that there will be examples of how to set those, for people who aren't familiar.
The test branch (WIP 2.0.0) is far from finished. I just don't have a lot of time to contribute to the library and am fixing up that branch when I can.
Mike Helmick Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Wednesday, July 3, 2013 at 1:38 PM, Travis Fischer wrote:
Hello, If you are open to some feedback I have some thoughts on the tests branch. If you don't want feedback than please just ignore this. I understand that not everyone has time or desire to pursue learning testing best practices. First of all, if you are going to ship tests with your project and include them in the repo they should be able to be run by anyone who clones the repo. Your import of "from .secret_keys import MAILCHIMP_API_KEY" prevents this from happening. Additionally, you probably don't want to hit the actual mailchimp API servers every time tests are run. As you are probably already aware, the tests you have written are functional tests that test the full system stack in an actual "production like" deployment. These tests are fine to have for your own purposes in your personal build and deployment process but the kind of tests you want to write and include in your open source repository are unit tests as well as functional tests that are isolated just to testing your code base but "mocking" or "stubbing" away an external dependencies. Unit tests allow people working on your project to test that their changes haven't broken any functionality when they alter the code. Unit tests should be able to be run "out of the box" by anyone who clones your repository. Unit tests should be able to be run anytime, all the time, by a lot of different people meaning you generally don't want to be sending network traffic or hitting live APIs in unit tests. Unit tests can be a bit tricky to write when you are first starting. For a good example of how to write unit tests for a library that actually uses the same API as you are using, I would recommend checking out this project and the tests that the maintainer has written: https://github.com/ericrasmussen/postmonkey/blob/master/postmonkey/tests.py I commend you for at least beginning the process of writing tests. It's a great first step. However, for this library to be useful to as many people as possible in the open source community you really do need to add some proper unit tests. It's definitely worth reading up on testing and specifically unit testing if you are going to be active in the open source community. I would highly recommend this book: http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
— Reply to this email directly or view it on GitHub (https://github.com/michaelhelmick/python-mailsnake/issues/9#issuecomment-20432272).