Installing Test Case and Code Coverage Environment on Webstorm

Now that you are using this technology and tool stack - Angular JS, Jasmine for test cases, Karma as coverage reporter, require js and Webstorm as the IDE, why not make all in one! If you are not using Grunt to run tasks, you may setup these in Webstorm itself. Just one click will run your test cases and code coverage in the Webstorm console.

For confidentiality reasons, I could add attach images from actual code to this post, so the screen grabs that you see here are downloaded from the web.

These steps may help you with the setup:

1)   First pre-requisite for this is to have node js and npm installed globally.
NPM tips-
  a) To install npm, run npm install –g npm. Then run npm init to get the package.json generated. This will ask you a bunch of questions, and then write a package.json for you. It attempts to make reasonable guesses about what you want things to be set to, and then writes a package.json file with the options you've selected. If you already have a package.json file, it'll read that first, and default to the options in there.
  b) Use npm cache clean when you have no clue of what’s going on. 

2)   In Webstorm, go to File-> Settings. Enable karma as coverage reporter, if not already enabled. To configure code coverage , refer this URL http://www.jetbrains.com/webstorm/webhelp/run-debug-configuration-karma.html
3)      Run the following commands on the project folder –
          npm install -g karma-chrome-launcher
    npm install karma-chrome-launcher
    npm install -g karma-cli
    npm install karma-cli
    npm install -g karma-coverage
    npm install karma-coverage
    npm install -g karma-jasmine
    npm install -g karma-requirejs
    npm install -g requirejs

4)   Look for tests-karma-config.js in your project's folder, set this location as the basePath in this file. In the preprocessor section of this file, add the path to the js files for which you need to check code coverage.
5)   Look for tests-main.js parallel to tests-karma-config.js. In the require section, add the reference to the file that belongs to the module we are to test. Remove the other file references. For example, -
'folder-name/module-name/tests/index'

6)  In the index.js, for which we have provided path above, add reference to the file you need to test.
7)   In the project folder, create a folder called coverage and add a new file coverage.html to that. This is where you will see your code coverage reports.
8)   In the directory explorer of Webstorm, right click on tests-karma-config.js, select Run tests-karma-config.js with coverage. The terminal will open automatically, which would open the browser in turn. Alternatively, you can open the Webstorm terminal, and reach upto the project folder through command, and then run this command, karma start tests-karma-config.js.

9)   The output of test cases will be displayed in the terminal itself. For coverage report, html files for coverage should have been created in the coverage folder (See screen grab below). Navigate to the folder and open the html file in browser.

Should I use CSS Reset?

The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on.

The question of which CSS Reset to use is one that developers and designers spend far too much time worrying about. In this article, I’ll cover two important points that can hopefully offer a little insight into the thought process: 

Firstly, to simplify and clarify what exactly we need from a good CSS Reset (and what we don’t!)
Second – and more importantly – to persuade people to stop just using the same, unmodified CSS Reset that came with their framework, without giving any thought to it.

When you include a CSS Reset in your stylesheet, you’re actually asking the browser to do an awful lot of work, in that you’re applying a CSS style to every single element on the page. This is totally fine, as long as you know what you’re doing (in any case, it’s only older browsers that will struggle with this.) Then, after zero-ing out every element’s default browser style, we go on to restyle them with fairly complex CSS rules. Not highly optimised, but it works.

The issue is that many people just stuff in any old CSS Reset without modification, which must be avoided.

Eric Meyer, when he pioneered the technique of CSS Reset (Eric Meyer’s Reset CSS), explicitly stated that:

The reset styles given here are intentionally very generic. I don’t particularly recommend that you just use this in its unaltered state in your own projects. It should be tweaked, edited, extended, and otherwise tuned to match your specific reset baseline. Fill in your preferred colors for the page, links, and so on.

With this, he persuades developers to build on top of his Reset stylesheet, to hack it, tweak it, make it their own, and then (possibly) republish it.

Scrum At a Glance

What Are Agile & Scrum?
Agile is an umbrella term used to describe a general approach to software development. Though there are many agile incarnations, all agile processes, including Scrum emphasize teamwork, frequent deliveries of working software, close customer collaboration, and the ability to respond quickly to change.

This post talks about the basic elements of Scrum, and a little understanding for a team to get started with Scrum Model for their project development.

 The term "scrum" originated from the game of rugby, and the culture of team work behind this sport. It's about "we", not "me". Rugby has one simple rule which defines game play more than any other: there is no forward passing. In order to work the ball down the field, it must be passed many times from player to player, as the team attempts to push through their opponent’s defense and score.

Elements of Scrum

Sprint
A sprint or an iteration is the basic unit of development in scrum, which generally lasts for a period of 2-4 weeks (decided in advance). At the end of the sprint, the team is able to deliver an integral unit of the product which is potentially shippable.

 

ROLES

Scrum Master
The scrum master organizes scrum events, helps remove any impediments, helps maintain scrum principles in the team.

Development Team 
The development team is responsible for developing the product. The size of the team must be 7 ± 2.

Product Owner
The Product Owner writes user stories, communicates with stakeholders to understand business needs, and maintains the product backlog in order of priority.

SCRUM CEREMONIES

Sprint Planning
During Sprint Planning, the team commits to the work to be done in a sprint. In exchange, the Product Owner agrees not to change the scope of the work expected of the team during the sprint. When the team makes this "deal", it empowers the team to take ownership over the sprint and its success. A Scrum team should be committed to the success of the sprint, willing to do whatever it can to carry it out effectively.

Sprint Retrospective
A sprint retrospective meeting is facilitated by the Scrum Master. The team reflects on their practice, congratulates each other on their successes, and refocuses themselves on any improvements they can make. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?

Sprint Review
In a sprint review meet, the team reviews the work that was completed, and plans for the remaining work. It is demonstrated to the stake holders.

Daily Scrum Meeting (Stand-up Call)
This event occurs daily for 15 minutes where each of the member of the team shares their status (What did I do yesterday, What will I do today and impediments, if any). It is facilitated by the scrum master, who also notes and helps in resolving the impediments.

Backlog Grooming Meeting
It is also called as Backlog refinement. It is the ongoing process of reviewing product backlog items and checking that they are appropriately prioritized and prepared in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity.

SCRUM ARTIFACTS

Product Backlog
The product backlog comprises an ordered list of requirements that a scrum team maintains for a product. The product owner orders the product backlog items (PBIs) based on considerations such as risk, business value, dependencies, and date needed. Items added to a backlog are commonly written in story format (called user stories).

Sprint Backlog
The sprint backlog is the list of work the development team must address during the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the development team feels it has enough work to fill the sprint.

Burn Down Chart

• Sprint Burn Down Chart-  It is chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. During the sprint, each member picks up tasks from the sprint backlog and works on them. At the end of the day, they update the remaining hours for tasks to be completed. In such way the actual burndown chart is updated day by day.

• Release burn-down chart- The release burndown chart is the way for the team to track progress and provide visibility. The release burndown chart is updated at the end of each sprint by the scrum master. The horizontal axis of the release burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint.

Grunt: Getting Started

These days web application's life cycle is not limited to mere coding, but how the whole execution takes place, the application's performance, code quality, efficient maintenance of large applications and ease of release. To accomplish all this, UI development phase has taken a leap in terms of usage of modern tools. Grunt is one such powerful tool.

Grunt is a task runner that can dramatically improve your front-end development workflow. With the use of a number of grunt plugins you can automate tasks such as compiling LESS, optimizing images and validating your JavaScript code with JSHint.

Grunt deals with frontend automation. The tasks that need to be performed by developers are simplified by using automation. It is similar to Maven that is used for Java development.

Grunt.js is a task-based command line tool written in JavaScript on top of the Node.js platform. Grunt is a task runner that can dramatically improve your front-end development workflow. You can write your most complicated tasks once and leverage them in all of your projects using project specific configuration with the help of grunt.js. 

 

In this blog post you are going to learn how to set up Grunt and configure some recommended tasks.

A few of the most recommended tasks for a web application are –

1. JS Hint - JSHint is a community-driven tool to detect errors and potential problems in JavaScript code and to enforce your team's coding conventions. It is very flexible so you can easily adjust it to your particular coding guidelines and the environment you expect your code to execute in.  
2. Concatenation – To enhance performance of your webapp, and speed up the processing concatenation and minification are helpful. A bunch of files concatenated into one at the run time would reduce loading time on the browser. 
3. Minification – Minification is also required for the same purposes as concatenation. It involves removal of all the unnecessary characters from js code which include white spaces, new line characters, comments etc, which are used to add readability to the code but are not required for it to execute. 
4.  Optimize images - Optimizing images can often yield some of the largest byte savings and performance improvements for your website: the fewer bytes the browser has to download, the less competition there is for the client's bandwidth and the faster the browser can download and render useful content on the screen. Although optimization can be done at the designer’s end itself,
5. Preprocessing – This task would output the generated code from a preprocessor like CSS file out of LESS or SASS and js file from .coffee file.

A grunt setup simply comprises of – package.json (lists the grunt and grunt plugins) and Gruntfile (used to define or configure tasks and load grunt plugins). The package.json file involves minimal learning for the developers who are acquainted with JSON.

Installing the Grunt Command Line Interface
Our first job is to install the Grunt command line interface. This is responsible for locating the grunt library in your project and loading the Gruntfile.js configuration.

Grunt and Grunt plugins are both installed using npm, the Node.js package manager. If you don’t have Node.js installed on your machine visit the download page and grab the installer for your operating system. Follow the steps in the installation wizard and you should be up and running in no time. npm is included in the install.

Once you have Node.js and npm installed you can install the grunt-cli package.

npm install -g grunt-cli

Creating a package.json File
Now that you’ve got the Grunt CLI installed it’s time to install the Grunt task runner.

In order to better manage the dependencies for your project it’s best to create a package.json file.

The package.json file should be placed in the root of your project. This file defines data about the project such as the project name, version and author. The package.json file is also responsible for managing dependencies. The devDependencies property defines the different packages that are needed for your application.

{
 "name": "project-name", 
 "version": "0.1.0",
 "author": "Your Name", 
 "devDependencies": {

       "grunt": "~0.4.1", 

       "grunt-contrib-jshint": "~0.6.3", 

       "grunt-contrib-watch": "~0.5.3"      

    }

}

This is a basic example of package.json. To check out all available properties, visit the official documentation.

To install all the dependencies, run the following command-

npm install

This command will fetch all of the packages and store them in a new node_modules directory in your project route.  To install additional packages, you may run the below command, specifying the name of the package you wish to install.

npm install <module> --save-dev

Using the --save-dev flag will cause npm to automatically add this package to the dependencies in your package.json file.

Defining Tasks in the Gruntfile
Once you are done with package.json and npm installation, it's time to add tasks to your grunt file.
Create a file called Gruntfile.js. This is where you define and configure the tasks that you want Grunt to run.

Lets take a look at an example that uses the plugins specified in your package.json file.

module.exports = function(grunt) {

  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    watch: {
      css: {
        files: [
          '**/*.css',
          '**/*.less'
        ]
      },
      js: {
        files: [
          'assets/js/*.js',
          'Gruntfile.js'
        ],
        tasks: ['jshint']
      }
    },
    jshint: {
      options: {
        jshintrc: '.jshintrc'
      },
      all: ['Gruntfile.js', 'assets/js/*.js']
    }
  });

  grunt.loadNpmTasks('grunt-contrib-watch');
  grunt.loadNpmTasks('grunt-contrib-jshint');

  // Register the default tasks.
  grunt.registerTask('default', ['watch']);
}; 

You may go over the list of available plugins to look for more plugins.

LOADING THE PLUGINS 
The next section in the Gruntfile is used for loading each of the plugins you wish to use. These need to be specified in your package.json file and installed using npm install. If you try to run grunt without installing a plugin it will just display an error.

// Load the Grunt plugins.
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-jshint');

REGISTERING THE DEFAULT TASKS 
The grunt.registerTask method is used specify a default set of tasks that should run when the grunt command is executed.

// Register the default tasks. 
grunt.registerTask('default', ['watch']);

The first parameter of this method specifies the name of the task (in this case ‘default’) and the second contains an array of the tasks you wish to be executed. The watch task we defined earlier takes care of calling the jshint task, so we only need to specify watch here.

Running Grunt 
Now you are done all the above steps, its time to run your grunt tasks and see how it automates your UI workflow.

Executing the grunt command in your terminal will run all of the tasks specified in your default task. You can also run tasks individually by passing the task name to the grunt command.

grunt // Runs default tasks 
grunt jshint// Just runs the compass task

Verdict 
Grunt is a good place to start automating your UI workflow. There are several other tools like Gulp, but the former wins due to its extensive usage,large community support, wide range of plugins and speed.

Do have a look at what Addy Osmani has to share on Modern UI Workflow here.