overview mock servers

[Patrick Mulder]

Hi,

@Erik: indeed, my last email was not send to the group, but directly to you.

So, here is again the overview of Mock servers that I found on Github:

just did a github search and there are some interesting ideas:

- connect and grunt based:

https://github.com/sahibinden/connect-api-mocker

- json file based

 http://jsonplaceholder.typicode.com/

- https://github.com/barbaracassani/mockREST

 - https://github.com/magalhas/httpd-mock

- https://github.com/twalker/mocki

and client-side mock:

- https://github.com/rynonl/apimok

- https://github.com/thopham/backbone-mockjax

and express based:

https://github.com/epixa/strapi

Will, start reading about the Ember approaches next.

Cheers,

Patrick

[Patrick Mulder]

Mocking on the client-side with https://github.com/trek/ember-testing-httpRespond and/or mockjax look quite interesting indeed.

The advantage would be not having to run any server-process for development, and it would be nicely fitting with Grunt. Maybe interesting to compare with https://github.com/rynonl/apimok too.

I try to explore this tomorrow too.

[Erik Trom]

yes many fun things to explore... im at 35,000 feet on an airplane... i bought wifi for the day, even though i only have 2 short flights, so that i could install and play with koa...

[Erik Trom]

well koa only works with node 0.11.9 and therefore isn't very practical quite yet..

i don't really know what i'm talking about most of the time but it sure is fun to pretend...

generators seem interesting nonetheless...

perhaps i'll try making one of those crazy promise chains i was talking about in my overly long post from earlier this week... 

and to all a good night

- Erik

[Patrick Mulder]

Mockjax looks very interesting for a first browser-side mock approach: http://ja.mesbrown.com/2012/04/adventures-in-mockjax/

I guess httprespond is very similar, also this blog post looks interesting: http://backstage.soundcloud.com/2011/09/mobile-unit-testing/

Ok, I am going to wire something up (mockjax intercepting requests, modules provide mockdata), and see how it turns out.

--
You received this message because you are subscribed to the Google Groups "Thoraxjs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thoraxjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik Trom]

awesome sounds good, i'll take a look when your done, still a bit pre-occupied with friends and family....

cheers

- Erik

[Patrick Mulder]

rightfully so :)

have fun!

[Patrick Mulder]

not much, and not yet completely wired up, but a start: https://github.com/mulderp/thorax-blog/commit/0722aebc8c3d0d649e4fdf9303a7504cd8bdb4af

I did a small experiment for my book though, and there I got it working already.

Update later, girlfriend is expecting me offline :)

[Patrick Mulder]

Here is a working setup with Mockjax: https://github.com/mulderp/thorax-blog/commit/3a03ad5d406114c40c5e309b537b0c84cb51dce7

The only problem now is that by introducing the Mock in requirejs, the mock is somewhat prone to get into the production build, if I understand that correctly.

Does requirejs allow to mark some dependencies/code for development purposes only?

[Erik Trom]

in tasks/options/requirejs.js lies the requirejs config file that is used during production builds -- its used in place of /requirejs-config.js.. perhaps we could set a path in that file that points to a noop version of the mocks module? 

playing with what you've got at the moment, im digging it so far...

- Erik

[Patrick Mulder]

sounds good.

just back from some days of holidays, and playing around with the previous setup and Mockjax.

Not sure, if there is a problem with my setup or something else.

When loading the Thorax example in the browser, and do:

t = require('thorax'); C = t.Collections

Posts = C.posts; posts = new Posts

posts.fetch();

I see:

MOCK GET: /api/posts

Object {url: "/api/posts", type: "GET", isLocal: false, global: true, processData: true…}

jquery.mockjax.js:546

Which is good, still

posts.size()

> 0

Also, defining a collection parse seems not to get called.

So, I wonder if I miss something in the mockjax setup.

Ok, update later.

[Patrick Mulder]

by the way, just missed this small mock project last time I guess:

https://github.com/biril/backbone-faux-server

[Erik Trom]

howdy patrick... i'm back on the computer today as well although i must admit i am a bit pre-occupied with node streams but will be in the chat room in a bit... (couple hours or so from now)

in regard to your question about posts.size(), i noticed that the post.json file contains an array of values, perhaps it should contain an array of objects, such as [{id: 1, author: 'mulderp'}] ? I'm not sure if that will solve this problem, but i know backbone depends on the id key in particular...

- Erik

[Erik Trom]

just fyi, i'm actually in #thorax now... i'm actually trying to build an irc chat client for the browser so you should be able to find me there all week too... (except friday)

- Erik

[Erik Trom]

Hey patrick just thought of something in regard to this question:

What is the overall goal? One thing I just realized is that when we get to 'saving a post' we'll need to save the data somewhere in order to verify that functionality works. I think this may be a place where mocking on the client falls down, any thoughts?

We could just assert(manually or with a test) that the POST http method was invoked, etc.. perhaps that is enough... however, unless your using this functionality for testing, perhaps actually saving the data to a database would be more helpful during development, that way you could add some posts and make sure that things like css, etc also are coming out right... 

anyway, just something i thought of... if this turns out to be the case our thoughts on this topic may swing back towards node (or even rails... or some form of persistence. local storage is another option)

- Erik