Mocking network…

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Mocking network…

Uko2
HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.

Is there anything like this in Pharo?

Uko
Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Chris Muller-3
A mock network will never test as thoroughly as locahost network..

On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>
> Is there anything like this in Pharo?
>
> Uko

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

NorbertHartl

> Am 02.03.2016 um 17:27 schrieb Chris Muller <[hidden email]>:
>
> A mock network will never test as thoroughly as locahost network..
>
Why? Please elaborate!

Norbert

> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>
>> Is there anything like this in Pharo?
>>
>> Uko
>


Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Stephan Eggermont-3
In reply to this post by Chris Muller-3
On 02/03/16 17:27, Chris Muller wrote:
> A mock network will never test as thoroughly as localhost network.

Based on the posts of @danLuu and @aphyr I would say there is a lot to
be said for mocking the network & file system.

https://aphyr.com
http://danluu.com/file-consistency/

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Chris Muller-4
In reply to this post by NorbertHartl
I assume the mock object does not exercise any real network code or primitives.

On Wed, Mar 2, 2016 at 2:43 PM, Norbert Hartl <[hidden email]> wrote:

>
>> Am 02.03.2016 um 17:27 schrieb Chris Muller <[hidden email]>:
>>
>> A mock network will never test as thoroughly as locahost network..
>>
> Why? Please elaborate!
>
> Norbert
>
>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>
>>> Is there anything like this in Pharo?
>>>
>>> Uko
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Frank Shearar-3
In reply to this post by Chris Muller-3
Er. How do you reliably inject arbitrary network faults in your
localhost network again?

frank

On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
> A mock network will never test as thoroughly as locahost network..
>
> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>
>> Is there anything like this in Pharo?
>>
>> Uko
>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Chris Muller-4
I use a framework designed for testing network programs.  Depending on
the test, it launches 3-5 "player" copies of the image solely for
participation in the tests.  The controlling image runs the unit
tests, which each send their dance of rpc messages to the players to
make them run the tests in a controlled fashion.

The failure tests involve setting a boolean flag in the server image
that causes it to execute "Smalltalk quitPrimitive" from a place deep
in the system -- i.e., at one place in mid disk-write, to exercise the
recovery code.

This approach to testing network programs is heavier-weight than a
mock and doesn't integrate well with the SUnit browser.  But it does
provide me a comfortable context that assures me it really does work
over the network.  Back then, I was wanting to learn and practice my
TCP socket programming anyway, so it was hard for me to allocate time
to learning a mock which.. at the end of the day, I knew, would nag me
to wonder whether my program would really work over the network for
real.


On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <[hidden email]> wrote:

> Er. How do you reliably inject arbitrary network faults in your
> localhost network again?
>
> frank
>
> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>> A mock network will never test as thoroughly as locahost network..
>>
>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>
>>> Is there anything like this in Pharo?
>>>
>>> Uko
>>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Uko2
Look guys,

I know that you can start a super smart discussion about the approaches to test network-related stuff.

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 to https://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.

Cheers.
Uko

> On 03 Mar 2016, at 03:53, Chris Muller <[hidden email]> wrote:
>
> I use a framework designed for testing network programs.  Depending on
> the test, it launches 3-5 "player" copies of the image solely for
> participation in the tests.  The controlling image runs the unit
> tests, which each send their dance of rpc messages to the players to
> make them run the tests in a controlled fashion.
>
> The failure tests involve setting a boolean flag in the server image
> that causes it to execute "Smalltalk quitPrimitive" from a place deep
> in the system -- i.e., at one place in mid disk-write, to exercise the
> recovery code.
>
> This approach to testing network programs is heavier-weight than a
> mock and doesn't integrate well with the SUnit browser.  But it does
> provide me a comfortable context that assures me it really does work
> over the network.  Back then, I was wanting to learn and practice my
> TCP socket programming anyway, so it was hard for me to allocate time
> to learning a mock which.. at the end of the day, I knew, would nag me
> to wonder whether my program would really work over the network for
> real.
>
>
> On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <[hidden email]> wrote:
>> Er. How do you reliably inject arbitrary network faults in your
>> localhost network again?
>>
>> frank
>>
>> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>>> A mock network will never test as thoroughly as locahost network..
>>>
>>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>>
>>>> Is there anything like this in Pharo?
>>>>
>>>> Uko
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

NorbertHartl
In reply to this post by Frank Shearar-3
+1

> Am 03.03.2016 um 01:16 schrieb Frank Shearar <[hidden email]>:
>
> Er. How do you reliably inject arbitrary network faults in your
> localhost network again?
>
> frank
>
>> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>> A mock network will never test as thoroughly as locahost network..
>>
>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>
>>> Is there anything like this in Pharo?
>>>
>>> Uko
>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

NorbertHartl
In reply to this post by Chris Muller-4
I think that is one of the good points. If I test an interface of sending an request and getting a response I'm not interested in network stuff. I want to test my software and not my network stack. And I like to force errornous behavior in order to test error handling of my software. Finally I want to habe reliable tests which is hard to achieve if you allocate system resources. That means I don't want to randomly shuffle port numbers and hope it doesn't clash if tests are executed in parallel.

It is just that mocks are hard to apply.

Norbert

> Am 02.03.2016 um 22:15 schrieb Chris Muller <[hidden email]>:
>
> I assume the mock object does not exercise any real network code or primitives.
>
>> On Wed, Mar 2, 2016 at 2:43 PM, Norbert Hartl <[hidden email]> wrote:
>>
>>> Am 02.03.2016 um 17:27 schrieb Chris Muller <[hidden email]>:
>>>
>>> A mock network will never test as thoroughly as locahost network..
>> Why? Please elaborate!
>>
>> Norbert
>>
>>>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>>
>>>> Is there anything like this in Pharo?
>>>>
>>>> Uko
>>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Denis Kudriashov
In reply to this post by Uko2
Hi.

I just want to mention another interesting opportunity for mocking network.
In past we built system which retrieves information from various web services without documentation about data formats and protocols.
We created mock library which caches retrieved information from first calls and then in test we got network responses without internet requests. By demand we ran tests with empty cache to check that all services not change their protocols. It was really boost our productivity.

It will be nice to get such feature in Pharo.



2016-03-03 9:01 GMT+01:00 Yuriy Tymchuk <[hidden email]>:
Look guys,

I know that you can start a super smart discussion about the approaches to test network-related stuff.

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 to https://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.

Cheers.
Uko

> On 03 Mar 2016, at 03:53, Chris Muller <[hidden email]> wrote:
>
> I use a framework designed for testing network programs.  Depending on
> the test, it launches 3-5 "player" copies of the image solely for
> participation in the tests.  The controlling image runs the unit
> tests, which each send their dance of rpc messages to the players to
> make them run the tests in a controlled fashion.
>
> The failure tests involve setting a boolean flag in the server image
> that causes it to execute "Smalltalk quitPrimitive" from a place deep
> in the system -- i.e., at one place in mid disk-write, to exercise the
> recovery code.
>
> This approach to testing network programs is heavier-weight than a
> mock and doesn't integrate well with the SUnit browser.  But it does
> provide me a comfortable context that assures me it really does work
> over the network.  Back then, I was wanting to learn and practice my
> TCP socket programming anyway, so it was hard for me to allocate time
> to learning a mock which.. at the end of the day, I knew, would nag me
> to wonder whether my program would really work over the network for
> real.
>
>
> On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <[hidden email]> wrote:
>> Er. How do you reliably inject arbitrary network faults in your
>> localhost network again?
>>
>> frank
>>
>> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>>> A mock network will never test as thoroughly as locahost network..
>>>
>>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>>
>>>> Is there anything like this in Pharo?
>>>>
>>>> Uko
>>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Skip
In reply to this post by Uko2
Yes I agree. The way I test the GitHub API now is by running a local server which returns my JSON representation..

I looked at other API bindings to GitHub written in ruby to find an approach for testing[1].
A nice feature I saw there was recording requests in a "Cassette".
This way you run your requests once "live", and afterwards everything can be done offline

1: https://github.com/peter-murach/github#7-testing

2016-03-03 9:01 GMT+01:00 Yuriy Tymchuk <[hidden email]>:
Look guys,

I know that you can start a super smart discussion about the approaches to test network-related stuff.

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 to https://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.

Cheers.
Uko

> On 03 Mar 2016, at 03:53, Chris Muller <[hidden email]> wrote:
>
> I use a framework designed for testing network programs.  Depending on
> the test, it launches 3-5 "player" copies of the image solely for
> participation in the tests.  The controlling image runs the unit
> tests, which each send their dance of rpc messages to the players to
> make them run the tests in a controlled fashion.
>
> The failure tests involve setting a boolean flag in the server image
> that causes it to execute "Smalltalk quitPrimitive" from a place deep
> in the system -- i.e., at one place in mid disk-write, to exercise the
> recovery code.
>
> This approach to testing network programs is heavier-weight than a
> mock and doesn't integrate well with the SUnit browser.  But it does
> provide me a comfortable context that assures me it really does work
> over the network.  Back then, I was wanting to learn and practice my
> TCP socket programming anyway, so it was hard for me to allocate time
> to learning a mock which.. at the end of the day, I knew, would nag me
> to wonder whether my program would really work over the network for
> real.
>
>
> On Wed, Mar 2, 2016 at 6:16 PM, Frank Shearar <[hidden email]> wrote:
>> Er. How do you reliably inject arbitrary network faults in your
>> localhost network again?
>>
>> frank
>>
>> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>>> A mock network will never test as thoroughly as locahost network..
>>>
>>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>>
>>>> Is there anything like this in Pharo?
>>>>
>>>> Uko
>>>
>



Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Esteban A. Maringolo
In reply to this post by Frank Shearar-3
So we're not mocking "a network", but a webserver instead. Am I right?

Or are we mocking faults in the bottom level? (like connection
aborted, and stuff like that).

Regards!
Esteban A. Maringolo


2016-03-02 21:16 GMT-03:00 Frank Shearar <[hidden email]>:

> Er. How do you reliably inject arbitrary network faults in your
> localhost network again?
>
> frank
>
> On 2 March 2016 at 08:27, Chris Muller <[hidden email]> wrote:
>> A mock network will never test as thoroughly as locahost network..
>>
>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>> HI, there is one thing in Ruby (on Rails) that I really like and it is a option to mock network. This means that when you run a test your network requests are handled by a mock object and you can tell it that for this URI it should give you this response. This is helpful if you don’t want to rely on a network availability or test certain corner cases.
>>>
>>> Is there anything like this in Pharo?
>>>
>>> Uko
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Mocking network…

Alain Rastoul-2
In reply to this post by Uko2
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