Getting Started with ngCordovaMocks

  • Estimated read time: 3 min read
  • Written by Chad Campbell on Aug 19th 2014

At this point, you've probably been introduced to ngCordovaMocks. You either like what you've heard, or, at the very least, you're curious. Regardless of the reason, this post assumes you're familiar with Bower and Grunt. With that in mind, let's get started with ngCordovaMocks.

Loading ngCordovaMocks

For ease of use, ngCordovaMocks is available via Bower. You can add ngCordovaMocks to your project by adding the package to your bower.json file. The package name is ngCordovaMocks. The latest version number can be found in the version property value here. As of the time of this writing, the following worked:

bower install ng-cordova-mocks

The process of loading a module via Bower is probably already familiar to you. If you prefer to build the code locally, you can clone the source repository from here, and build it with Grunt. Either way, after you have the ngCordovaMocks module, you need to configure your build process.

Configuring your Build Process

The choice to use ngCordovaMocks comes at build time instead of run time. This design decision was made for several reasons. First, I wanted to keep my production code as clean as possible. Second, I wanted ngCordovaMocks to stand on its own. In the event that a better library comes along, I wanted to be able to easily swap it out. Once again, as described during the introduction, this module was created to get something done quickly.

The process I use relies on a Grunt plugin called grunt-text-replace. I create a task target called development. When used, this target looks for instances of @@cordovaScript in the src files specified in the src property. All instances of @@cordovaScript are replaced with /vendor/ng-cordova-mocks/dist/ngCordovaMocks.js. This is shown in the following snippet:

development: {
  src: [
    'temp/index.html',
    'temp/app/app.js'
  ],
  overwrite: true,
  replacements:[
    { from: '@@cordovaScript', to:'/vendor/ng-cordova-mocks/dist/ngCordovaMocks.js' },
    { from: '@@ngCordova', to:'ngCordovaMocks' }
  ]
}

There are three other interesting points in this snippet.

  1. Instances of @@ngCordova are replaced with ngCordovaMocks. The reason why is because I'm assuming I'm running my code in either a browser or via Karma. You may consider naming your task something like browser.development is a personal preference consistent with my development workflow.

  2. The replacements only happen in two files! In reality, the ngCordovaMocks.min.js file should only be needed in index.html because I'm essentially building a Single Page Appliction. Loading the mocks library over ngCordova is handled by the second replacement string. That will most likely happen in app.js. To gain a better understanding of this approach, please look at the official ngCordova docs. The reason I deliberately specify to only look in two files is to speed up my build time.

  3. The files specified in the src property look in a temp directory. This approach assumes that all of your code is copied to a temp directory prior to the grunt-text-replace task. This is needed because this task updates my code. I would like to keep my original code so that I can build across different environments.

At this point, I hope you're able to get up-and-running with ngCordovaMocks. You can learn how to use ngCordovaMocks in your automated tests by looking at the ngCordovaMocks API. If you like what you see, please tell other developers by using the toolbar below. If you need help with your software projects, please contact me.


Comments

comments powered by Disqus

Chad Campbell
Chad Campbell

Chad is an independent software professional. He has been named a Microsoft MVP five times. His books have been translated into multiple languages and distributed worldwide. He holds a computer science degree from Purdue University, where he also studied psychology.

Chad has built sites, apps, frameworks, libraries, and platforms using Java, .NET, and Node. He's ran his own startups and has created software for Fortune 100 companies. In short, Chad knows how to create software. From ideation to delivery. From start-to-finish.


Follow Chad Online