ember-addon – hangaroundtheweb

Setting up Coveralls for your Ember Addons

In this tutorial, we will see how to setup automated code coverage metrics collection for your Ember addons using Coveralls and Github Actions.

Why Code coverage?

In simple terms, code coverage is the fraction or percentage of code paths executed by some test or test suite of a program. It is generally measured by a tool which executes the test and logs the lines of code, the test “touches” while running. At its most basic, every conditional statement creates a “branch” defining two unique code paths, and theoretically, both “branches” of each condition must be executed by the test suite in order for the developer to be certain that the code works correctly in each condition.

Code coverage is often used as a metric to determine the effectiveness of Unit tests. Low coverage typically means that developers are not writing adequate unit tests. This signifies that there are many code paths in the application which may possibly behave incorrectly.

ember-cli-code-coverage

This addon provisions to gather Code coverage for your Ember apps and addons using Istanbul. Install this addon into your Ember app or addon with ember install;

ember install ember-cli-code-coverage

1	ember install ember-cli-code-coverage

The latest version published on npm is 0.4.2. This might be a very old version and not Octane compatible, you might run into some errors while running the tests. But there is a latest one in Github release with the tag v1.0.0-beta.9. If you are running into any problems with the npm package , you can directly install the 1.x beta version using yarn or npm.

npm install --save-dev kategengler/ember-cli-code-coverage#v1.0.0-beta.9

1	npm install --save-dev kategengler/ember-cli-code-coverage#v1.0.0-beta.9

Or using yarn

yarn add --save-dev kategengler/ember-cli-code-coverage#v1.0.0-beta.9

1	yarn add --save-dev kategengler/ember-cli-code-coverage#v1.0.0-beta.9

Coverage will only be generated when an environment variable is true (by default COVERAGE) and running your test command like normal.

COVERAGE=true ember test

1	COVERAGE=true ember test

Coveralls

Coveralls is a language-agnostic and CI-agnostic web service to help you track your code coverage over time, and ensure that all your new code is fully covered.

Add your github repo for the app/addon to Coveralls using Add Repos option in the website.

After adding the repo, Coveralls will provide you with a repo token, which we need to identify the repo with Coveralls. You need to add a Github Secret with the value of this token in your repo. This will be later used in our Github actions to set up the COVERALLS_REPO_TOKEN environment variable before sending coverage information to Coveralls.

env:
  COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}

1 2	env: COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}

Install the coveralls node package.

npm install --save-dev coveralls

1	npm install --save-dev coveralls

Configure your test script to include coverage information.

"scripts": {
   ...
   "test:ember": "COVERAGE=true ember test ",
   ...
 },

"scripts": {

...

"test:ember": "COVERAGE=true ember test ",

...

Add a separate coveralls script to upload the coverage information to Coveralls service.

"scripts": {
   ...
   "coveralls": "cat ./coverage/lcov.info | coveralls",
   ...
 },

"scripts": {

...

"coveralls": "cat ./coverage/lcov.info | coveralls",

...

This will upload the coverage statistics generated while running tests in a folder called coverage in a file known as lcov.info

Generating coverage statistics in CI

If you want to generate coverage information and upload it to Coveralls while running your tests in CI whenever you push your code to the repo or whenever a pull request is raised, you can go for some automated CI setup using Travis or Github Actions. In this tutorial we are going to look at how we can achieve this using Github Actions.

Github actions for Coveralls

This GitHub Action posts your test suite’s LCOV coverage data to coveralls.io for analysis, change tracking, and notifications. You don’t need to add the repo to Coveralls first, it will be created when receiving the post.

When running on pull_request events, a comment will be added to the PR with details about how coverage will be affected if merged.

Create a new job for your Github Actions or add it part of the existing one.

on: ["push", "pull_request"]

name: Test Coveralls

jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:

    - uses: actions/checkout@v1

    - name: Use Node.js 10.x
      uses: actions/setup-node@v1
      with:
        node-version: 10.x

    - name: npm install, run coveralls
      env:
        COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}
      run: |
        npm install
        npm test:ember
        npm run coveralls

    - name: Coveralls
      uses: coverallsapp/github-action@master
      with:
        github-token: ${{ secrets.GITHUB_TOKEN }}

on: ["push", "pull_request"]

name: Test Coveralls

jobs:

build:

name: Build

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v1

- name: Use Node.js 10.x

uses: actions/setup-node@v1

with:

node-version: 10.x

- name: npm install, run coveralls

env:

COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}

run: |

npm install

npm test:ember

npm run coveralls

- name: Coveralls

uses: coverallsapp/github-action@master

with:

github-token: ${{ secrets.GITHUB_TOKEN }}

If you want to see the above setup in action, please take a look at my ember-chance addon repo.

Optional Goodies: README Badge

And finally if you want to add the coverage statistics as a badge in your README, you can do so by adding the following snippet at the top of your README file, which will show how much the coverge % is for your addon.

[![Coverage Status](https://coveralls.io/repos/github/&lt;github-user-name>/&lt;repo-name>/badge.svg?branch=master)](https://coveralls.io/github/&lt;github-user-name>/&lt;repo-name>?branch=master)

1	[![Coverage Status](https://coveralls.io/repos/github/<github-user-name>/<repo-name>/badge.svg?branch=master)](https://coveralls.io/github/<github-user-name>/<repo-name>?branch=master)

Please ensure to replace the above snippet with the appropriate values for the placeholders like <github-user-name> and <repo-name>

Recap

Install ember-cli-code-coverage
Install coveralls from npm
Modify the test script in package.json to include COVERAGE=true
Add a new script for coveralls to upload the coverage info
Add your repo to Coveralls.io and get the repo_token
Add a Github secret with the value of the repo_token in the repository
Setup automated coverage collection in CI using Coveralls Github Actions

References:

Creating an accessible toggle component in Ember

How to create an accessible toggle component in Ember?

In this tutorial, we are going to create an accessible toggle component in Ember using the WAI-ARIA specifications.

A toggle or switch component is a type of checkbox that represents on/off values, as opposed to checked/unchecked values.

First we are generate the component by firing up our ember-cli tool:

> ember g component aria-switch

1	> ember g component aria-switch

The default component skeleton will look like this.

import Component from '@ember/component';
import layout from '../templates/components/aria-switch';

export default Component.extend({
  layout,

});

import Component from '@ember/component';

import layout from '../templates/components/aria-switch';

export default Component.extend({

layout,

});

Next we are going to import the computed and reads methods from ‘@ember/object’ and ‘@ember/object/computed’. We are using the new module syntax which will make Ember applications start faster, by replacing the Ember global with a first-class system for importing just the parts of the framework you need.

To know more about the new module syntax, please refer to this RFC.

import { reads } from '@ember/object/computed';
import { computed } from '@ember/object';
import Component from '@ember/component';
import layout from '../templates/components/aria-switch';

export default Component.extend({
   layout,

});

import { reads } from '@ember/object/computed';

import { computed } from '@ember/object';

import Component from '@ember/component';

import layout from '../templates/components/aria-switch';

export default Component.extend({

layout,

});

Next we concentrate on the component template for now. The template code is very simple since we are just going to have some labels for ON and OFF, since we are going for the primary button in the component, the template is only going to have two span elements like this:

<span> {{onLabel}} </span>
<span> {{offLabel}} </span>

1 2	<span> {{onLabel}} </span> <span> {{offLabel}} </span>

Next we will add a checked property to notify the toggle state whether it is on or not.

checked: false

1	checked: false

ARIA attributes

The following are the list of ARIA attributes our switch component will be using and the purpose of each and every attribute is listed below:

aria-checked

The aria-checked attribute of a switch indicates whether the input is on (true) or off (false).

aria-label

The aria-label defines a string value that labels the current element. The purpose of aria-label is to provide the user with a recognizable name of the object.

aria-labelledby

The aria-labelledby attribute identifies the element (or elements) that labels the current element. The purpose of aria-labelledby is the same as that of aria-label.

role

The role attribute allows the author to annotate markup languages with machine-extractable semantic information about the purpose of an element. Use cases include accessibility, device adaptation, server-side processing, and complex data description. In our case, the role attribute will be assigned a value of switch to indicate that it is a toggle button.

HTML Attributes

In addition to the ARIA attributes mentioned above, the switch component will also make use of some HTML attributes for manipulating the markup and controlling the behaviour of the component.

data-action

dataAction: 'aria-switch'

1	dataAction: 'aria-switch'

data-keep-disabled

dataKeepDisabled: reads('disabled'),

1	dataKeepDisabled: reads('disabled'),

type

type: 'button',

1	type: 'button',

So the final set of attributeBindings will be something like:

attributeBindings: [
    'ariaChecked:aria-checked',
    'ariaLabel:aria-label',
    'ariaLabelledBy:aria-labelledby',
    'dataAction:data-action',
    'dataKeepDisabled:data-keep-disabled',
    'disabled',
    'role',
    'type',
  ]

attributeBindings: [

'ariaChecked:aria-checked',

'ariaLabel:aria-label',

'ariaLabelledBy:aria-labelledby',

'dataAction:data-action',

'dataKeepDisabled:data-keep-disabled',

'disabled',

'role',

'type',

]

Then we will have a property called ariaChecked which will read the checked property passed to the component.

ariaChecked: computed('checked', function() {
    return this.get('checked') ? "true" : "false";
  })

ariaChecked: computed('checked', function() {

return this.get('checked') ? "true" : "false";

})

Then finally we will handle the click event for the component. We can handle the same in the default click() event, which does two things. One we need to toggle the checked property, second we need to invoke the callback function passed to the component once the status is toggled.

click() {
   this.toggleProperty('checked');
   if(this.get('onToggle')) {
     this.get('onToggle')(this.get('checked'));
   }
 }

click() {

this.toggleProperty('checked');

if(this.get('onToggle')) {

this.get('onToggle')(this.get('checked'));

}

The final code for the component.js will look something like this:

import { reads } from '@ember/object/computed';
import { computed } from '@ember/object';
import Component from '@ember/component';
import layout from '../templates/components/aria-switch';

export default Component.extend({
  layout,
  checked: false,
  dataAction: 'aria-switch',
  offLabel: 'Off',
  onLabel: 'On',
  role: 'switch',
  type: 'button',
  tagName: 'button',
  attributeBindings: [
    'ariaChecked:aria-checked',
    'ariaLabel:aria-label',
    'ariaLabelledBy:aria-labelledby',
    'dataAction:data-action',
    'dataKeepDisabled:data-keep-disabled',
    'disabled',
    'role',
    'type',
  ],
  ariaLabel: reads('label'),
  dataKeepDisabled: reads('disabled'),
  ariaChecked: computed('checked', function() {
    return this.get('checked') ? "true" : "false";
  }),
  click() {
    this.toggleProperty('checked');
    if(this.get('onToggle')) {
      this.get('onToggle')(this.get('checked'));
    }
  }
});

import { reads } from '@ember/object/computed';

import { computed } from '@ember/object';

import Component from '@ember/component';

import layout from '../templates/components/aria-switch';

export default Component.extend({

layout,

checked: false,

dataAction: 'aria-switch',

offLabel: 'Off',

onLabel: 'On',

role: 'switch',

type: 'button',

tagName: 'button',

attributeBindings: [

'ariaChecked:aria-checked',

'ariaLabel:aria-label',

'ariaLabelledBy:aria-labelledby',

'dataAction:data-action',

'dataKeepDisabled:data-keep-disabled',

'disabled',

'role',

'type',

ariaLabel: reads('label'),

dataKeepDisabled: reads('disabled'),

ariaChecked: computed('checked', function() {

return this.get('checked') ? "true" : "false";

}),

click() {

this.toggleProperty('checked');

if(this.get('onToggle')) {

this.get('onToggle')(this.get('checked'));

}

});

Now we can invoke our component like this:

{{aria-switch label="My Label" checked=true}}

1	{{aria-switch label="My Label" checked=true}}

With custom on/off labels

{{aria-switch onLabel="Yes" offLabel="No" class="toggle toggle-primary"}}

1	{{aria-switch onLabel="Yes" offLabel="No" class="toggle toggle-primary"}}

With toggle callback

{{aria-switch onToggle=(action 'toggleCallback')}}

1	{{aria-switch onToggle=(action 'toggleCallback')}}

Source Code and Demo

References:

Image Credits:

Photo by Mikkel Bech on Unsplash