Re:Test driven development at Transloadit
by boundlessdreamz on Thursday October 28, 2010 @11:18AM
(#1843189)
How do you test something which requires browser interaction like oauth authentication?
Edit: I know this may not be applicable in transloadit's case. I'm asking for a general strategy
Re:Test driven development at Transloadit
by felixge on Thursday October 28, 2010 @11:23AM
(#1843227)
The core of our service is a REST API, so we don't have to deal with that much. For browser interaction we would probably use a combination of Selenium (for system tests), and maybe qunit for the frontend testing.
But anyway, I am no expert on this so I can't give you solid advice.
Re:Test driven development at Transloadit
by johnwatson11218 on Thursday October 28, 2010 @02:11PM
(#1844109)
I have used canoo webtest to test browser interaction that involved a log in to a deployed server.
Re:Test driven development at Transloadit
by knuckle_cake on Thursday October 28, 2010 @02:11PM
(#1844111)
One method I've used (with Ruby) is use of FakeWeb, and collecting the various responses from oauth providers to test against. It's the closest I've seen to hitting the real services.
If you're testing javascript, you'll need to use Selenium or something similar.
Re:Test driven development at Transloadit
by ollysb on Thursday October 28, 2010 @10:31PM
(#1845815)
Webmock is an excellent ruby framework for solving this problem. My current app intereracts with both github and heroku and it's come in very handing for filling in what would otherwise be gaps. It's newer than fakeweb and is much better at letting you specify interactions on a per test basis rather than the entire suite.
So generally you need to try to find a small enough product so you can build it using TDD. Also stay as simple as you can with your testing - even if it feels very repetitive. I'm only now thinking of adding more tools to my testing toolchain after I have a better understanding of the actual problems I run into often.
About testing web APIs. You need both unit and system tests. The unit tests make sure your internal processing is solid. The system tests will directly make calls to the service. That won't always feel pretty, but it's the best way to approach it IMO.