JavaScript testing – Requests

Dog is testing the the crackers for poison.

When testing JavaScript you might have run into the problem of testing requests, such as XmlHttpRequests (XHR). You might also have run into an awesome way of testing it such as the one provided by Buster.js (which in turn uses Sinon.js). These tools are really powerful and awesome, if you haven’t tried them yet go do it.

One problem though. A unit test is supposed to be as implementation independent as possible, and testing XHR is rather tightly bound to the implementation. If I suddenly start requesting resources by adding script tags to the dom my tests will fail even though the solution is solid. We don’t want that.

Continue reading

JavaScript testing – Requests

Dog is testing the the crackers for poison.

When testing JavaScript you might have run into the problem of testing requests, such as XmlHttpRequests (XHR). You might also have run into an awesome way of testing it such as the one provided by Buster.js (which in turn uses Sinon.js). These tools are really powerful and awesome, if you haven’t tried them yet go do it.

One problem though. A unit test is supposed to be as implementation independent as possible, and testing XHR is rather tightly bound to the implementation. If I suddenly start requesting resources by adding script tags to the dom my tests will fail even though the solution is solid. We don’t want that.

Continue reading

JavaScript testing – Requests

Dog is testing the the crackers for poison.

When testing JavaScript you might have run into the problem of testing requests, such as XmlHttpRequests (XHR). You might also have run into an awesome way of testing it such as the one provided by Buster.js (which in turn uses Sinon.js). These tools are really powerful and awesome, if you haven’t tried them yet go do it.

One problem though. A unit test is supposed to be as implementation independent as possible, and testing XHR is rather tightly bound to the implementation. If I suddenly start requesting resources by adding script tags to the dom my tests will fail even though the solution is solid. We don’t want that.

Continue reading

RfTouch sees light

RfTouch is a framework for Sencha Touch 2. As it is right now the project is at it’s very beginning. Currently it offers a ReloadStore, which is a simple addition to the default store, so it can handle reloads. In it self it’s nothing special, just a simplification of a common usage when using ST 2 as part of a native app.

To try it out go to https://github.com/rohdef/rftouch and download the RfTouch folder. Put the folder in your project and adding RfTouch to the loader:

Then you can create your own store, almost like you’d normally create a store, except that you extend RfTouch.data.ReloadStore.

From here on you should just listen to the bailout event, which specifies that the store didn’t get any successful response from the proxy and use the resetReload method if you want to reset the retry count (note that to start with the retry count is 0, so load will also work on the first load, but will not if the bailout handler allows retrying).

Upcomming: RfMap – an Ext.Map that handles connectivity.