Jasmine Unit Tests in an RxJs + Firebase app: Part 2

For today’s post, we’ll cover some useful test execution shortcuts and then dive into how to test code that uses AngularFire’s database.list.push() method to write data into the database.

Jasmine Test Execution Shortcuts

Part 1 covered describe and it, functions that are part of Jasmine that provide BDD-style tests. We looked at the following simple test:

describe("The Alert Helper", () => {

   // DI, setup, and beforeEach code elided

  it("should create an error alert with a provided message", () => {
    spyOn(AlertCtrlStub.prototype, "create").and.callThrough();

    alertHelper.triggerErrorAlert("This is a message!");

      message: "This is a message!",
      buttons: [
          text: "Ok",
          role: "cancel",

As you can see describe can be used to mark a suite of tests and each individual test can live in an it.

Now consider what happens when you build up enough tests in your application that it takes awhile for your entire test suite to run . . .


Jasmine Unit Tests in an RxJs + Firebase app: Part 1

Unit testing can be…well….different in an app built on libraries devoted to functional, asynchronous paradigms. AngularFire 2 may well be the epitome of this. There’s a lot to unpack. It’s TypeScript for one thing, not just plain JS. On top of that, add the RxJs library. Firebase‘s realtime database feature is both real-time and NoSql for another thing. It uses WebSocket so all the RxJs stuff really does sit around emitting events whenever data changes in Firebase. Phew! This does not make things plain and simple!

I’ve gathered some experience with it the past eight months in an Ionic mobile app, and here are the tips and tricks I have gathered, collected, stumbled upon, and cringed over. We used Jasmine as the test framework in my application, and these examples do the same.

By no means do I mean the examples below to be prescriptive or otherwise thought of as “the way to do things.” Probably there are better ways. But they have worked for me and my team. I encourage anyone to provide suggestions and feedback in the comments section.

Getting started with first things first: setup . . .

Basics of fault-tolerant Promises in TypeScript

Recently I’ve been spending some time developing an Ionic 2 mobile app, which uses Angular and TypeScript.

I have noticed a couple places where my team has code similar to this:

someCallThatReturnsAPromise().then( () => {
  someOtherCallThatReturnsAPromise().then( () => {
}, (err) => {
  this.alertHelper.triggerErrorAlert("Hi an error happened: " + err.message);

This works but it suppresses errors . . .

Non-functional requirements are important yet often forgotten


Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.

Just to set some context, I would describe “functional requirements” as software requirements that . . .


Tackling Map.get()’s null-returning anti-pattern

In the beginning was Dictionary and HashTable, and they returned null when a call to get() was made. And the darkness prevailed over the land. And programmers found many NullPointerExceptions in production and confusion reigned on the face of the deep.

Then lo Map and HashMap were created. And there was great rejoicing, because their performance was greatly improved. And yea the royal order of code scribes did thus feel a great advance.

But confusion still reigned on the face of the deep, and null was returned on every call to get() . . .