Stubbing Rubymotion Http
This is a seriously old post. I’d probably not bother reading it, but I keep it here for nostalgia.
Stubbing RubyMotion HTTP
Coming from the Ruby and Rails world, I’m anchored in the paradigm that we should test our code. Our code should not only be tested, but it should be sure not to be hitting external services during those specs. I’ve had a hard time figuring out the best way to stub out HTTP calls effectively and easily in RubyMotion. I’m also not the best Objective-C programmer, so porting libraries already built was not on the cards in the timeframe I wanted.
However, I came across the WebStub library by Matt Green in my search for answers, and played around with it over the weekend. It’s fantastic. Coupled with Clay Allsop’s AFMotion library that creates a ruby bridge to the AFNetworking library.
Let’s run through how I went about testing a little API driven app I’m writing. I assume you have RubyMotion, and that you’re not new to using it, but you’re unfamiliar with how to test HTTP calls. It uses BubbleWraps HTTP calls, not AFMotion, however it’s the same testing method.
Create a RubyMotion Project
We’re going to clone the brilliant API Driven Example written by Clay Allsop. Did I mention he wrote the RubyMotion Book? It’s good. Buy it. The API Driven example on the RubyMotion Tutorial is ripe for a little sprinkle of test. So go ahead and run through that example if you want to play along with me adding specs to it.
Once you have that, we’ll start adding our specs. I’ve cloned the git repository that Clay has kindly placed this in, and taken the Colr application straight out of it.
In the Color class, we have 2 HTTP calls, one is a GET and the other is a POST. Let’s wrap a test around that GET request first. The find
method looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Add WebStub to your Rakefile.
1 2 3 4 5 6 7 8 9 10 |
|
Here’s the color_spec.rb
spec I built to demonstrate testing that call.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
|
Things to Note
First, we need to engage the WebStub library, and disable any network access. WebStub will let us know of any unauthorised networked access and block it, perfect for debugging url’s.
1 2 3 4 5 |
|
Set up the response that WebStub should give you if you call the stubbed URL. This is better done from fixtures, but for verbosity I’m putting it here for now.
1
|
|
Now, set up WebStub to listen on the URL that we’re calling for this test.
1 2 |
|
Here’s the fun part. HTTP calls are done in a separate thread from the main thread, so catching when they’re done requires a little ‘hooking’. We put the resume
method call in the block, my understanding is that this is like calling thread.join
in Ruby. We want to wait for it to return in our test thread, not go running off all by itself and returning results to the abyss.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
That’s all there is to it. If you’re using AFMotion like me, your specs will look just the same. The only difference being I usually abstract the service layer to it’s own module/class so I can switch it out later if I have issues.
I hope that helped.