AngularJS Backend-less Development Using a $httpBackend Mock
I was only able to briefly mention that I used a $httpBackend mock to do backend-less development with AngularJS during my presentation on AngularJS Data Driven Directives, so I created an isolated example in a Plunker to fully implement it. Here is a link to the Plunker if you want to skip right there, below is an explanation and the embedded plunker.
The purpose of this example code is to show how to do backend-less development with code that uses both $http and $resource to fully cover the most common server communication options within AngularJS.
Why do backend-less development?
Isolating your AngularJS frontend development from the backend (REST API) can allow potentially separate teams develop independently. Agreeing on the REST API can then allow both teams develop in parallel, agreeing to implement/use the REST service the same way.
This can be accomplished by the simple inclusion of a file in your AngularJS code that creates a mock using $httpBackend. $httpBackend makes the requests that are underlying $http, which is also what ngResource $resource uses. When you are ready to hit the real backend REST API, simple remove the file from being included, possibly as simple as a special task inside your grunt config.
There are two different flavors of the $httpBackend mock, we want to use the one not for unit testing, but for E2E testing:
AngularJS $httpBackend docs
How do we do it?
We use URL patterns within app-mockbackend.js to intercept the GET and POST calls to the URLs, along with the data for a POST. We can use regular expressions as patterns, which allows for a lot of flexibility.
The handling of the URLs and HTTP methods and returning "fake" data only works by having some data that can be persistent from request to request. I store the data in an AngularJS service ServerDataModel that emulates storing the data a lot like the server would. The AngularJS service recipe is perfect for this becuase it injects a constructed object, and that object contains our data. No matter where it is injected, the instance of the object is what is shared so it contains the same data. There is some data that is pre-loaded in that object that is analagous to having a database on the server that already has some records.
Here is the embedded version of the code, although I do think it is easier to view in its full glory directly on Plunker.