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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> wrote: > >>> A mock network will never test as thoroughly as locahost network.. > >>> > >>> On Wed, Mar 2, 2016 at 6:32 AM, Yuriy Tymchuk <[email protected]> > 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 > >>> > > > > >
