On 03/03/2016 09:01, Yuriy Tymchuk wrote:
But my question was super simple. If I’m writing something that accesses github
I can write a test for handling request limit error. And in ruby I can say: “ok
in this test when you get a request tohttps://github…………/SomePathThatITest
hive a response with this number and this headers”. And then I can test the
result. If I cannot do this in Pharo, then I will not test it, it’s that easy.
Hi Yuriy,
Yes you can ... :)
But it depends on what you want to mock : the client or the server.
If I had network code I would use ZnClient, then in my tests I would
just mock the client (just MHO).
Esteban's idea of mocking the server is interesting but sounds hard to
implement.
Suppose you have:
"instance var ?"
| client |
"client initialization somewhere in my code or test"
client := ZnClient new.
"... then later in my test"
client get: 'http://zn.stfx.eu/zn/numbers.txt'.
I would do:
"instance var ?"
| client |
"client initialization somewhere in test setup"
client := MySimpleMock new.
"or MyObject client: MySimpleMock new. if there is an accessor"
"still in test setUp
to respond with error 30% of the time "
client on: #get:
with: #('http://zn.stfx.eu/zn/numbers.txt')
return: [ (1 to: 10) atRandom > 7
ifTrue: [ self error: 'Some Network Error Here ...' ].
"normal response"
ZnResponse ok: (ZnEntity text: 'OK for this one') ] .
"... then later "
client get: 'http://zn.stfx.eu/zn/numbers.txt' .
"would return what you expect, with 30% errors"
I did a SimpleMock class like this one who just returns expected answers
in the Icecompiler package on smalltalkhub (IceSimpleMock).
Very basic, but simple to extend if needed (may be it would be useful to
package it separately?).
And there is also Mocketry that you may investigate, sounds great (from
ESUG slides).
I didn't, I'm lazy, I just do what I need.
HTH
--
Alain
