It's amusing that this post about some raft of dependencies that is supposed to make testing easy, painless and fun opens with a mini-rant about an earlier module that was supposed to make things super easy and fun, but ended up causing the author pain.
This seems like a common Rails tradeoff (trading quick development time for dependency chasing and complexity), except it's rarely presented as a tradeoff.
Surely this is a community-wide iterative search and, although it can be annoying to keep up with, it should be seen as a good thing (unlike other communities which stagnate around one dominant concept)
I have used the tool in question and recently abandoned it for the same setup described in the article, I'm guessing for the same reasons he did.
Cucumber is only annoying if you don't need to use it. A lot of people who didn't really need it were using it in the rails world, and recently they have got sick of it.
If you have an actual business need for executable documentation like it provides, then it is still excellent and not a headache.
I know this would slow down your integration tests and complicate them, but wouldn't you want to avoid mocking twitter this way to actually test that your site is integrating properly with the service? Mocking obviously has its place, but I'd avoid it if possible for end to end testing like this.
I have this challenge and I'm very interested in seeing how others solve this without using mocks. For my tests, I have 5 tests that rely on Twitter logins. Given that I run my tests ~10 times per day (on each commit), and other developers run my tests on their commits, I would have number_of_developers * commits_per_developer_per_day * 5 logins per day with a real twitter account. My guess is that that would run afoul of twitter's policies.
I'd love to see a web based stubbing service that would let me test against Twitter and especially Facebook without using real accounts on either.
Proper in this case: OmniAuth abstracts away the actual OAuth process and, as is always proper, you should be testing your application code not your libraries.
You should mostly just ensure that the requests your software makes are correct, and that you're testing response handling with correct responses; what actually happens at the other end is of no concern to you.
At some point, of course, you may want to run actual integration (preferably against test users/whatever) but that needn't be a part of your regular test suite, so you can for example add an env toggle to actually perform remote connections, or have a separate normally-excluded set of tests for that.
10 comments
[ 0.18 ms ] story [ 31.1 ms ] threadThis seems like a common Rails tradeoff (trading quick development time for dependency chasing and complexity), except it's rarely presented as a tradeoff.
Cucumber is only annoying if you don't need to use it. A lot of people who didn't really need it were using it in the rails world, and recently they have got sick of it.
If you have an actual business need for executable documentation like it provides, then it is still excellent and not a headache.
I'd love to see a web based stubbing service that would let me test against Twitter and especially Facebook without using real accounts on either.
I don't know if twitter offers anything similar.
At some point, of course, you may want to run actual integration (preferably against test users/whatever) but that needn't be a part of your regular test suite, so you can for example add an env toggle to actually perform remote connections, or have a separate normally-excluded set of tests for that.