Sign up for the FREE Learning AngularJS Newsletter

Since I like using AngularJS and the current client project and the last few client projects I’ve been on use AngularJS, I realized there may be others out there who want to start learning AngularJS or enhancing their current AngularJS web apps. So I started a newsletter where we post the newest books, tutorials, articles, modules and code libraries that AngularJS developers should check out.

Click here to start getting the newsletter!

You can click here to check out the Learning AngularJS Archives before you sign up.

AngularJS: testing services that use $resource

Currently I’m working on a project that uses ngResource (imported into the code as $resource) and the unit tests related to the service relying on $resource were failing. I jumped in to do a rewrite or to scrap them entirely if necessary.

My tool kit:

  • Karma test runner
  • Jasmine unit testing/spying/mocking framework

The service looked something like this:

The Problem

How to unit test a service that relies on $resource was the problem. When I searched around on how to test services or factories that rely on $resource, it appeared that people were trying to mock out $resource which didn’t work. Most of them also tried what we see above and mocked out $httpBackend. This partially works, but didn’t allow for the forcing of certain code paths which is necessary for getting maximum test coverage.

Unit Tests Vs. Integration Tests

AngularJS uses dependency injection to make it easier to test things like this, but once you’re mocking out objects like $httpBackend and $resource, you’re no longer writing a unit test. You’re instead writing an integration test.

An integration test works by testing the class and its integration with other dependencies. With $resource-based services, your unit test for the service is an integration test.

The Solution

After some days of searching StackOverflow and other tutorials and articles on how to unit test AngularJS services that use $resource, “Working Effectively With Legacy Code” gave me an answer in a few minutes of reading: move the functionality into a new class.

To break the dependency of the service on $resource, I used the advice of “Working Effectively With Legacy Code”. This is a wonderful book that every software developer should have on their shelves or on their ebook reader. Great reference books are a god-send and quickly help you solve a problem.

The reason for this is that the callback functions given to the $resource promise are private functions. There is no way of accessing them until you call the promise and force it.

To avoid writing unit tests based on mocking and to avoid having inaccessible/untestable functions, I moved the callback functions to a new class and the OriginalResource now only contains methods that require $resource:

There is now a new service, Original, that doesn’t rely on $resource. The old service, OriginalResource, hooks up the new service to the $resource class. This is far easier to test because you can invoke the success or failure callbacks whenever you like and check to make sure it changes the right parts of the system.

The conclusion: when you’re writing services that interact with the backend, you may need to break your service into two services to avoid mock objects. And this is okay! There’s nothing wrong with refactoring code to make it testable without having to resort to mocks.

Things I have learnt in the first 5 minutes of using Elastic Search

Rudolf Olah:

pretty much the same experience I’ve been having, at least the documentation part. it’s almost non-existent and single sentences to explain options in the query DSL are useless, there aren’t enough examples either.
what’s with JS and newer developers completely forgetting to write documentation? It’s strange and unfortunate.

Originally posted on Sammaye's Blog:

After hearing all the raving about Elastic Search and how it was awesome and “rad” or whatever “hip-young” programmers want to say I decided I would give it a go.

To get the point since this might be a bit tl;dr: I am not overly fond of it. I am unsure what companies like GitHub see in it.

It has a queue, no need for a river

Excactly that, implement it into your active record and you don’t need to river.

I would in fact advise agains the river, it ues the oplog which can be slow and not only that but you are adding yet another lock on top of the secondaries that are trying to read as well, which may increase your chances of replication falling behind, this is of course dependant upon how often the river pings your oplog and how many new ops you have in…

View original 1,689 more words

sweet.js macro for three.js (webgl)

sweetjs, threejs macro featured imageI know you’re not supposed to use macros when a simple function with a callback parameter will do, but I really wanted to try out sweet.js, the library that adds macro compilation to JavaScript.

I also started exploring three.js, a WebGL library.

The macro I wrote simplifies the render loop, you supply the scene and camera object and the body of the loop and you’re set. The macro sets up the renderer.

Again, not the most appropriate use of macros but it was a nice small way of getting used to macro definition syntax and to explore how much potential power there is.

There’s also a Grunt task plugin to run sweet.js which automates the whole macro compilation step. Just add file watching and reloading and the experience is pretty much the same as developing with CoffeeScript.

Hope this encourages other JS devs to check out what sweet.js can offer and maybe one day we’ll have a nice set of macros to simplify the common JS frameworks out there.

Cheers,
Rudolf
@go_august

PHPUnit Essentials Book Review

PHPUnit Essentials would have come in handy while on a
recent contracting gig and on all the other PHP projects I’ve worked
on. The book is published by Packt Publishing who seem to be the new
O’Reilly, the last book I bought from them was on AngularJS and it was
a great guide whereas as the O’Reilly book on AngularJS was outdated.

Overall the book was a good read and it’s worth getting as both a guide and a reference.
Continue reading

focused on coding, listening to Kygo and PSY

Lately I’ve been reading about WebRTC and figuring out how to use it at a lower level with C++ rather than with JavaScript.  I’ve been doing some more angularjs work and started on an A/B testing framework but now I have to figure out how I’m going to add drop-in support for multiple databases (because how else can you track which conversions were successful for your variations?).

Trying to figure out how the whole consulting business works out. Finding new clients is going well right but it’s the whole mindset of offering a recurring service using retainers or offering productized consulting which has me scratching my head.

Glad to have experienced the joys of being a pet owner though it’s only for a little while.

Trying to speed up the first generation Nexus 7 tablet and the only luck I’ve had is with disabling syncing, disabling Currents and removing games and apps that I’m no longer using. Keeping old games around can especially drain battery and kill speed because they’re running in the background sometimes. I’m not sure what else can be done to improve.

Using Google Play Music to store part of my music collection. Not sure yet whether to sign up for the monthly unlimited streaming.

Listening to PSY + Snoop Dogg – Hangover, and listening to Kygo: https://soundcloud.com/kygo

 

The GNU Coding Standards need an update

There was some discussion a while ago on the Libreplanet mailing list about creating a wiki called the GNU Developer Network, somewhat similar to the MDN (Mozilla Developer Network) and the MSDN (Microsoft Developer Network). I think it’s a great idea, free/open source developers need a wiki for more discussions and a general place for free software developers to find more info.

Someone suggested that the GNU Coding Standards point the way and that a wiki would just be duplicating whatever information exists in the GNU Coding Standards.

My idea is that developers, especially web developers, are picking up their habits from blogs and tutorials. They look to the MDN and other projects as guides to how their own projects should be structured and how their code should look. They use tools like Yeoman to generate their projects. The GNU Coding standards do not cover how to document JavaScript (java-docs style comments?) or how to handle Python (for example, requiring a setup.py or pip requirements file). We need sensible modern coding standards that people can use as a starting point for their projects.

Using a wiki lets developers suggest proposals in a forum other than a mailing list, which tend to be a little more exclusive. Using a wiki makes the documents living, and people won’t be afraid to spark a discussion about how and why sections of the standards need to be kept the same or updated.