    
|
|
|
|
|
The Web Content Accessibility Guidelines Working Group (WCAG WG) requests review of draft updates to Notes that accompany WCAG 2.0: Techniques for WCAG 2.0 (Editors’ Draft) and Understanding WCAG 2.0 (Editors’ Draft). Comments are welcome through 14 February 2014. (This is not an update to WCAG 2.0, which is a stable document.) To learn more about the updates, see the Call for Review: WCAG 2.0 Techniques Draft Updates e-mail. Read about the Web Accessibility Initiative (WAI).
]]>The National Science Foundation is sponsoring a Summer Research Experience in the Department of Physics and Astronomy at the University of Missouri (MU) to engage students in high quality research on topics in materials and modeling. The program is one of several research experiences being offered by MU’s Office of Undergraduate Research.
Acceptance to the program is competitive. At a minimum, students must:
A roundup of the most interesting stories from other sites, collected by the staff at MIT Technology Review.
China Cloning on an “Industrial Scale”
The BBC reports from China’s genome institute, the BGI. Together, the video and text give us a look at its pig cloning factory, where some 500 pigs are cloned each year to study human diseases and to try to improve yields on farms.
—Susan Young, biomedicine editor
The way that we interact with computers has changed dramatically over the past decade. Touch-screen devices and laptop trackpads have enabled a much more intuitive form of interaction than is achievable using a traditional mouse. These changes haven’t been limited to just hardware. Gestures, predictive text, and speech recognition are all examples of software innovations that have improved the way in which we interact with our devices.
Speech recognition has somewhat eluded innovators for decades. Many organizations have tried (with varying levels of success) to create reliable speech recognition technologies. There is one company however that looks to have cracked the problem – Google.
In this post you’ll be learning how to take advantage of Google’s speech recognition technologies to enhance your web forms. You’ll learn how to give Chrome users the ability to fill-in text fields using speech, and how to detect support for this new speech input capability in browsers.
Lets get started.
Enabling support for speech input is as simple as adding an attribute to your <input> elements. The x-webkit-speech attribute will indicate to the browser that the user should be given the option to complete this form field using speech input.
<input type="text" x-webkit-speech>When speech input is enabled the element will have a small microphone icon displayed on the right of the input. Clicking on this icon will launch a small tooltip to show that your voice is now being recorded. You can also start speech input by focussing the element and pressing Ctrl + Shift + . on Windows, or Command + Shift + . on Mac.
Speech Input in Chrome
In JavaScript, you can test to see if an element has speech input enabled by examining it’s webkitSpeech property. This is a boolean property and will therefore be set to true or false. You can override this property to enable or disable speech input on an element.
// Enable
element.webkitSpeech = true;
// Disable
element.webkitSpeech = false;Speech input is not available for all the different HTML5 input types. In my testing I found that the text, number, and tel types do support speech input whereas the email, url, date, and month input types don’t.
If you apply the x-webkit-speech attribute to an <input> element with an unsupported input type, the webkitSpeech property on that element will still be set to true. You therefore cannot rely on this property to tell if the browser is displaying the speech input controls, only that the browser supports speech input in general.
A simple way of checking if the user’s browser supports speech input is to look for the webkitSpeech property on an <input> element. An example of how to do this is shown below.
if (document.createElement('input').webkitSpeech === undefined) {
// Not supported
} else {
// Supported!
}Google Chrome is the only browser that currently supports speech input. We’ll examine the reasons for this in the next section.
Speech-to-Text with a Web Service
The browser relies on an external service to handle speech-to-text conversion. The recording of your voice is sent to this service which then analyses the audio and constructs a textual representation. The text is then sent back to the browser which populates the <input> element to complete the process. Many speech-to-text services incorporate machine-learning algorithms that allow them to get more accurate over time.
Note: A side effect of using an external service to handle speech-to-text is that you will need an internet connection for speech input to work. This is something to keep in mind if you plan for your web application to work offline.
The Chrome browser relies on Google’s proprietary speech recognition technology to provide the functionality behind x-webkit-speech. Google has had a team working on speech recognition and natural language processing for a long time. It’s this team that’s been responsible for developing the complex systems needed to provide a reliable speech-to-text service for products like Google Translate and Voice Search.
Note: If you’re interested in learning more about how speech-to-text works check out the research papers published by Google engineers.
Developing speech-to-text services is incredibly difficult and requires a significant amount of investment. This is probably the main reason why no other browser vendor has implemented speech recognition yet. However, now that Apple has acquired Siri, I’m interested to see if speech recognition will make it’s way into Safari some time soon.
In this post you’ve learned about the x-webkit-speech attribute and how it can be used to add speech input capabilities to your web forms. There is also a more advanced Web Speech API that we haven’t covered in this post. This API allows developers to add speech recognition functionality to more aspects of their applications, and even synthesize speech from text.
Whether it’s in the computer on your desk, or the phone in your pocket, software innovations like Google Voice Search and Siri are paving the way for a revolution in how we interact with computers. Welcome to the future my friends, now if only someone could figure out the whole teleportation thing.
The post Accepting Speech Input in HTML5 Forms appeared first on Treehouse Blog.
]]>|
|
When I started playing around with Ember.js almost a year ago, the testability story left something to be desired. You could unit test an object without any trouble, but a unit test is only one way to get feedback when you’re building a software product. In addition to unit tests, I wanted a way to verify the integration of multiple components. So like most people testing rich JavaScript applications, I reached for the mother of all testing tools, Selenium.
Now before I bash it, without a proper introduction, it’s worth mentioning that Selenium is a great way to verify your entire web application works with a full production-like database and all your production dependencies, etc. And from a QA perspective, this tool can be a great resource for teams who need end-to-end UI acceptance tests.
But over time, a seemingly small test suite built on Selenium can begin to drag the velocity of your team to a snails pace. One easy way to reduce this pain is to avoid building a large application in the first place. If you build a handful of smaller web applications instead, it might help keep you afloat for a little longer because no individual build will crush the team, as you grow.
But even on a small project, the real problem with Selenium is that it’s not part of the test driven development process. When I’m doing red/ green/ refactor I don’t have time for slow feedback in any form. I needed a way to write both unit and integration tests that would provide quick feedback to help me shape the software I was writing in a more iterative way. If you are using a version of Ember.js >= RC3, you’re in luck because writing a unit or integration test is a walk in the part.
Now that we can write JavaScript tests for our application, how do we execute them? Most developers start out using the browser directly, but because I wanted something I could execute headless from the command line in a CI environment with a rich ecosystem full of plugins, I looked to Karma.
What I liked about Karma is that it only wants to be your test runner. It doesn’t care what JavaScript test framework you use or what client side MVC framework you use. It’s simple to get started with and writing tests that execute against your production Ember.js application is just a few lines of configuration.
But before we can configure Karma, we need to install it using npm. I recommend installing it locally so you can keep your npm modules isolated per project. To do this, add a file named package.json‘ to the root of your project that looks something like the below.
{
"dependencies": {
"karma-qunit": "*",
"karma": "0.10.2"
}
}
This example will require both Karma, and a plugin for QUnit. After you save the package.json file above, drop back to the command line and type npm install to pull down the required Node modules.
After the npm install completes, you will now see a new folder with the name node_modules in the root of your project. This folder contains all the JavaScript code we just pulled down with npm, including Karma and the QUnit plugin. If you drill down even further to node_modules/karma/bin/ you will see the Karma executable. We will be using this to configure the test runner, execute tests from the command line, etc.
Next we need to configure karma so it knows how to execute the QUnit tests. Type karma init from the root of the project. You will be prompted with a list of questions. The first will ask what testing framework you want to use, hit Tab until you see qunit, then hit Enter. Next answer no to the Require.js question, as we won’t be using it for this sample application. Tab until you see PhantomJS for the third question and you will need to hit Enter twice as it allows multiple options here. As for the rest, just leave them at their default option.
When you are done, you should see Karma has generated a configuration file named karma.conf.js in the root or your project. If you want to read more about the various options Karma supports, you might find the comments helpful. For the sake of this example, I have a simplified version of the configuration file to keep things beginner friendly.
If you want to follow along, delete the generated configuration file and replace it with this one.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
This should be fairly similar to what Karma generated earlier, I’ve just removed all the comments and cut out a few options we don’t care about right now. In order to write the first unit test, I had to tell Karma a little more about the project structure.
At the top of the configuration file, you will see that I’ve set the basePath to js because all of the JavaScript assets live under this folder in the project. Next, I told Karma where it can find the JavaScript files required to test our simple application. This includes jQuery, Handlebars, Ember.js and the app.js file itself.
Now we can add the first unit test file to the project. First make a new folder named tests and nest it under the js folder. Add a file in this new directory named unit_tests.js that looks something like this.
test('hello world', function() {
equal(1, 1, "");
});
This test isn’t doing anything valuable yet, but it will help us verify we have everything wired up with Karma to execute it correctly. Notice in the Karma files section, we already added the js/tests directory. This way Karma will pull in every JavaScript file we use to test our application with, going forward.
Now that we have Karma configured correctly, execute the qunit tests from the command line using ./node_modules/karma/bin/karma start.
If you have everything setup correctly, you should see Karma execute one test and it being successful. To verify it executed the test we just wrote, go make it fail by altering the equals statement. For example, you could do the following:
test('hello world', function() {
equal(1, 2, "boom");
});
If you can fail this and make it pass again, it’s time to write a test with a little more purpose.
But before we get started, lets discuss the sample application used throughout this post. In the screenshot below, you see we have a very simple grid of users. In the HTML table, each user is shown by first name along with a button to delete that user. At the top of the application you will see an input for the first name, last name and finally a button that will add another user to the table when clicked.
https://dl.dropboxusercontent.com/u/716525/content/images/2013/pre-tuts.png
The example application has three problems. First, we want to show the user’s first and last name, not just the first name. Next, when you click a delete button it won’t actually remove the user. And finally, when you add a first name, last name and click add, it won’t put another user into the table.
On the surface, the full name change appears to be the simplest. It also turned out to be a great example that shows when you should write a unit test, an integration test or both. In this example, the quickest way to get feedback is to write a simple unit test that asserts the model has a computed property fullName.
Unit testing an ember object is easy, you simply create a new instance of the object and ask for the fullName value.
test('fullName property returns both first and last', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
});
Next if you go back to the command line and run ./node_modules/karma/bin/karma start, it should show one failing test with a helpful message describing fullName as undefined currently. To fix this, we need to open the app.js file and add a computed property to the model that returns a string of the combined first and last name values.
App.Person = Ember.Object.extend({
firstName: '',
lastName: '',
fullName: function() {
var firstName = this.get('firstName');
var lastName = this.get('lastName');
return firstName + ' ' + lastName;
}.property()
});
If you drop back to the command line and run ./node_modules/karma/bin/karma start you should now see a passing unit test. You can extend this example by writing a few other unit tests to show that the computed property should change when either the first or last name is updated on the model.
test('fullName property returns both first and last', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
});
test('fullName property updates when firstName is changed', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
person.set('firstName', 'wat');
result = person.get('fullName');
equal(result, 'wat billups', "fullName was " + result);
});
test('fullName property updates when lastName is changed', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
person.set('lastName', 'tbozz');
result = person.get('fullName');
equal(result, 'toran tbozz', "fullName was " + result);
});
If you add these two additional tests and run all three from the command line, you should have two failing. To get all three tests passing, modify the computed property to listen for changes on both the first name and last name. Now if you run ./node_modules/karma/bin/karma start from the command line, you should have three passing tests.
App.Person = Ember.Object.extend({
firstName: '',
lastName: '',
fullName: function() {
var firstName = this.get('firstName');
var lastName = this.get('lastName');
return firstName + ' ' + lastName;
}.property('firstName', 'lastName')
});
Now that we have a computed property on the model, we need to look at the template itself because currently we don’t use the new fullName property. In the past, you would need to wire up everything yourself, or use Selenium to verify the template gets rendered correctly. But with ember-testing you can now integration test this by adding a few lines of JavaScript and a plugin for Karma.
First open the package.json file and add the karma-ember-preprocessor dependency. After you update the package.json file, do npm install from the command line to pull this down.
{
"dependencies": {
"karma-ember-preprocessor": "*",
"karma-qunit": "*",
"karma": "0.10.2"
}
}
Now that you have the pre-processor installed, we need to make Karma aware of the template files. In the files section of your karma.conf.js file add the following to tell Karma about the Handlebars templates.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js",
"templates/*.handlebars"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
Next we need to tell Karma what to do with these handlebars files, because technically we want to have each template precompiled before it’s handed over to PhantomJS. Add the preprocessor configuration and point anything with a file extension of *.handlebars at the ember preprocessor. Also you need to add the plugins configuration to register the ember pre-processor (along with a few others that normally get included with Karma’s default configuration).
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js",
"templates/*.handlebars"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"],
plugins: [
'karma-qunit',
'karma-chrome-launcher',
'karma-ember-preprocessor',
'karma-phantomjs-launcher'
],
preprocessors: {
"**/*.handlebars": 'ember'
}
});
};
Now that we have the Karma configuration setup for integration testing, add a new file named integration_tests.js under the tests folder. Inside this folder we need to add a simple test to prove we can stand up the entire Ember.js application without error. Add a simple qunit test to see if we can hit the '/' route and get the basic HTML returned. For the initial test, we are only asserting that the table tag exists in the HTML that was generated.
test('hello world', function() {
App.reset();
visit("/").then(function() {
ok(exists("table"));
});
});
Notice we are using a few helpers that are built into ember-testing like visit and find. The visit helper is an ember friendly way of telling the application what state to be at during the execution. This test starts at the '/' route because that is where the People models get bound to the template and our HTML table is generated. The find helper is a quick way to lookup elements in the DOM using CSS selectors like you would with jQuery to verify something about the markup.
Before we can run this test we need to add a test helper file that will inject the test helpers and set a generic root element. Add the code below, to a file named integration_test_helper.js in the same tests directory. This will ensure our application has the test helpers at execution time.
document.write('<div id="ember-testing-container"><div id="ember-testing"></div></div>');
App.rootElement = '#ember-testing';
App.setupForTesting();
App.injectTestHelpers();
function exists(selector) {
return !!find(selector).length;
}
Now from the command line you should be able to execute the integration test above. If you got a passing test, remove the table from the handlebars template to make it fail (just to help prove Ember was generating the HTML using that template).
Now that we have the integration tests setup, it’s time to write the one that asserts we show each user’s fullName instead of their firstName. We want to first assert that we get two rows, one for each person.
test('hello world', function() {
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, rows);
});
});
Note: The application is currently returning hard coded data to keep everything simple at the moment. If you are curious why we get two people, here is the find method on the model:
App.Person.reopenClass({
people: [],
find: function() {
var first = App.Person.create({firstName: 'x', lastName: 'y'});
var last = App.Person.create({firstName: 'x', lastName: 'y'});
this.people.pushObject(first);
this.people.pushObject(last);
return this.people;
}
});
If we run the tests now, we should still have everything passing because two people are returned as we would expect. Next, we need to get the table cell that shows the person’s name and assert it’s using the fullName property instead of just firstName.
test('hello world', function() {
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, rows);
var fullName = find("table tr:eq(0) td:eq(0)").text();
equal(fullName, "x y", "the first table row had fullName: " + fullName);
});
});
If you run the above test you should see a failing test because we haven’t yet updated the template to use fullName. Now that we have a failing test, update the template to use fullName and run the tests using ./node_modules/karma/bin/karma start. You should now have a passing suite of both unit and integration tests.
If you are asking yourself, “when should I write a unit test vs. an integration test?”, the answer is simply: what will be less painful? If writing a unit test is faster and it explains the problem better than a much larger integration test, then I say write the unit test. If the unit tests seem less valuable because you are doing basic CRUD and the real behavior is in the interaction between components, I say write the integration test. Because the integration tests written with ember-testing are blazingly fast, they are part of the developer feedback cycle and should be used similarly to a unit test when it makes sense.
To show a CRUD like integration test in action, write the following test to prove the add button puts the person into the collection and that a new row gets rendered in the handlebars template.
test('add will append another person to the html table', function() {
App.Person.people = [];
App.reset();
visit("/").then(function() {
var rows = find("table tr").length
equal(rows, 2, "the table had " + rows + " rows");
fillIn(".firstName", "foo");
fillIn(".lastName", "bar");
return click(".submit");
}).then(function() {
equal(find("table tr").length, 3, "the table of people was not complete");
equal(find("table tr:eq(2) td:eq(0)").text(), "foo bar", "the fullName for the person was incorrect");
});
});
Start by telling the test what state you want to work with, then using the fillIn helper, add a first name and last name. Now if you click the submit button it should add that person to the HTML table, so in the returning then we can assert that three people exist in the HTML table. Run this test and it should fail because the Ember controller isn’t complete.
To get the test passing, add the following line to the PeopleController
App.PeopleController = Ember.ArrayController.extend({
actions: {
addPerson: function() {
var person = {
firstName: this.get('firstName'),
lastName: this.get('lastName')
};
App.Person.add(person);
}
}
});
Now if you run the tests using ./node_modules/karma/bin/karma start it should show three people in the rendered HTML.
The last test is the delete, notice we find the button for a specific row and click it. In the following then we simply verify one less person is shown in the HTML table.
test('delete will remove the person for a given row', function() {
App.Person.people = [];
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, "the table had " + rows + " rows");
return click("table .delete:first");
}).then(function() {
equal(find("table tr").length, 1, "the table of people was not complete
});
});")})})
To get this passing, simply add the following line to the PeopleController:
App.PeopleController = Ember.ArrayController.extend({
actions: {
addPerson: function() {
var person = {
firstName: this.get('firstName'),
lastName: this.get('lastName')
};
App.Person.add(person);
},
deletePerson: function(person) {
App.Person.remove(person);
}
}
});
Run the tests from the command line and you should once again have a passing suite of tests.
So that wraps up our sample application. Feel free to ask any questions down in the comments.
If you prefer to use Grunt instead of the karma-ember-preprocessor, simply remove the plugins and preprocessors configuration. Also remove templates/*.handlebars from the files section as Karma won’t need to precompile the templates. Here is a simplified karma.conf.js that works when using grunt to precompile the handlebars templates.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"lib/deps.min.js", //built by your grunt task
"tests/*.js"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
And that’s it!
]]>When I started playing around with Ember.js almost a year ago, the testability story left something to be desired. You could unit test an object without any trouble, but a unit test is only one way to get feedback when you're building a software product. In addition to unit tests, I wanted a way to verify the integration of multiple components. So like most people testing rich JavaScript applications, I reached for the mother of all testing tools, Selenium.
Now before I bash it, without a proper introduction, it's worth mentioning that Selenium is a great way to verify your entire web application works with a full production-like database and all your production dependencies, etc. And from a QA perspective, this tool can be a great resource for teams who need end-to-end UI acceptance tests.
But over time, a seemingly small test suite built on Selenium can begin to drag the velocity of your team to a snails pace. One easy way to reduce this pain is to avoid building a large application in the first place. If you build a handful of smaller web applications instead, it might help keep you afloat for a little longer because no individual build will crush the team, as you grow.
But even on a small project, the real problem with Selenium is that it's not part of the test driven development process. When I'm doing red/ green/ refactor I don't have time for slow feedback in any form. I needed a way to write both unit and integration tests that would provide quick feedback to help me shape the software I was writing in a more iterative way. If you are using a version of Ember.js >= RC3, you're in luck because writing a unit or integration test is a walk in the part.
Now that we can write JavaScript tests for our application, how do we execute them? Most developers start out using the browser directly, but because I wanted something I could execute headless from the command line in a CI environment with a rich ecosystem full of plugins, I looked to Karma.
What I liked about Karma is that it only wants to be your test runner. It doesn't care what JavaScript test framework you use or what client side MVC framework you use. It's simple to get started with and writing tests that execute against your production Ember.js application is just a few lines of configuration.
But before we can configure Karma, we need to install it using npm. I recommend installing it locally so you can keep your npm modules isolated per project. To do this, add a file named package.json' to the root of your project that looks something like the below.
{
"dependencies": {
"karma-qunit": "*",
"karma": "0.10.2"
}
}
This example will require both Karma, and a plugin for QUnit. After you save the package.json file above, drop back to the command line and type npm install to pull down the required Node modules.
After the npm install completes, you will now see a new folder with the name node_modules in the root of your project. This folder contains all the JavaScript code we just pulled down with npm, including Karma and the QUnit plugin. If you drill down even further to node_modules/karma/bin/ you will see the Karma executable. We will be using this to configure the test runner, execute tests from the command line, etc.
Next we need to configure karma so it knows how to execute the QUnit tests. Type karma init from the root of the project. You will be prompted with a list of questions. The first will ask what testing framework you want to use, hit Tab until you see qunit, then hit Enter. Next answer no to the Require.js question, as we won't be using it for this sample application. Tab until you see PhantomJS for the third question and you will need to hit Enter twice as it allows multiple options here. As for the rest, just leave them at their default option.
When you are done, you should see Karma has generated a configuration file named karma.conf.js in the root or your project. If you want to read more about the various options Karma supports, you might find the comments helpful. For the sake of this example, I have a simplified version of the configuration file to keep things beginner friendly.
If you want to follow along, delete the generated configuration file and replace it with this one.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
This should be fairly similar to what Karma generated earlier, I've just removed all the comments and cut out a few options we don't care about right now. In order to write the first unit test, I had to tell Karma a little more about the project structure.
At the top of the configuration file, you will see that I've set the basePath to js because all of the JavaScript assets live under this folder in the project. Next, I told Karma where it can find the JavaScript files required to test our simple application. This includes jQuery, Handlebars, Ember.js and the app.js file itself.
Now we can add the first unit test file to the project. First make a new folder named tests and nest it under the js folder. Add a file in this new directory named unit_tests.js that looks something like this.
test('hello world', function() {
equal(1, 1, "");
});
This test isn't doing anything valuable yet, but it will help us verify we have everything wired up with Karma to execute it correctly. Notice in the Karma files section, we already added the js/tests directory. This way Karma will pull in every JavaScript file we use to test our application with, going forward.
Now that we have Karma configured correctly, execute the qunit tests from the command line using ./node_modules/karma/bin/karma start.
If you have everything setup correctly, you should see Karma execute one test and it being successful. To verify it executed the test we just wrote, go make it fail by altering the equals statement. For example, you could do the following:
test('hello world', function() {
equal(1, 2, "boom");
});
If you can fail this and make it pass again, it's time to write a test with a little more purpose.
But before we get started, lets discuss the sample application used throughout this post. In the screenshot below, you see we have a very simple grid of users. In the HTML table, each user is shown by first name along with a button to delete that user. At the top of the application you will see an input for the first name, last name and finally a button that will add another user to the table when clicked.
https://dl.dropboxusercontent.com/u/716525/content/images/2013/pre-tuts.png
The example application has three problems. First, we want to show the user's first and last name, not just the first name. Next, when you click a delete button it won't actually remove the user. And finally, when you add a first name, last name and click add, it won't put another user into the table.
On the surface, the full name change appears to be the simplest. It also turned out to be a great example that shows when you should write a unit test, an integration test or both. In this example, the quickest way to get feedback is to write a simple unit test that asserts the model has a computed property fullName.
Unit testing an ember object is easy, you simply create a new instance of the object and ask for the fullName value.
test('fullName property returns both first and last', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
});
Next if you go back to the command line and run ./node_modules/karma/bin/karma start, it should show one failing test with a helpful message describing fullName as undefined currently. To fix this, we need to open the app.js file and add a computed property to the model that returns a string of the combined first and last name values.
App.Person = Ember.Object.extend({
firstName: '',
lastName: '',
fullName: function() {
var firstName = this.get('firstName');
var lastName = this.get('lastName');
return firstName + ' ' + lastName;
}.property()
});
If you drop back to the command line and run ./node_modules/karma/bin/karma start you should now see a passing unit test. You can extend this example by writing a few other unit tests to show that the computed property should change when either the first or last name is updated on the model.
test('fullName property returns both first and last', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
});
test('fullName property updates when firstName is changed', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
person.set('firstName', 'wat');
result = person.get('fullName');
equal(result, 'wat billups', "fullName was " + result);
});
test('fullName property updates when lastName is changed', function() {
var person = App.Person.create({firstName: 'toran', lastName: 'billups'});
var result = person.get('fullName');
equal(result, 'toran billups', "fullName was " + result);
person.set('lastName', 'tbozz');
result = person.get('fullName');
equal(result, 'toran tbozz', "fullName was " + result);
});
If you add these two additional tests and run all three from the command line, you should have two failing. To get all three tests passing, modify the computed property to listen for changes on both the first name and last name. Now if you run ./node_modules/karma/bin/karma start from the command line, you should have three passing tests.
App.Person = Ember.Object.extend({
firstName: '',
lastName: '',
fullName: function() {
var firstName = this.get('firstName');
var lastName = this.get('lastName');
return firstName + ' ' + lastName;
}.property('firstName', 'lastName')
});
Now that we have a computed property on the model, we need to look at the template itself because currently we don't use the new fullName property. In the past, you would need to wire up everything yourself, or use Selenium to verify the template gets rendered correctly. But with ember-testing you can now integration test this by adding a few lines of JavaScript and a plugin for Karma.
First open the package.json file and add the karma-ember-preprocessor dependency. After you update the package.json file, do npm install from the command line to pull this down.
{
"dependencies": {
"karma-ember-preprocessor": "*",
"karma-qunit": "*",
"karma": "0.10.2"
}
}
Now that you have the pre-processor installed, we need to make Karma aware of the template files. In the files section of your karma.conf.js file add the following to tell Karma about the Handlebars templates.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js",
"templates/*.handlebars"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
Next we need to tell Karma what to do with these handlebars files, because technically we want to have each template precompiled before it's handed over to PhantomJS. Add the preprocessor configuration and point anything with a file extension of *.handlebars at the ember preprocessor. Also you need to add the plugins configuration to register the ember pre-processor (along with a few others that normally get included with Karma's default configuration).
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"vendor/jquery/jquery.min.js",
"vendor/handlebars/handlebars.js",
"vendor/ember/ember.js",
"vendor/jquery-mockjax/jquery.mockjax.js",
"app.js",
"tests/*.js",
"templates/*.handlebars"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"],
plugins: [
'karma-qunit',
'karma-chrome-launcher',
'karma-ember-preprocessor',
'karma-phantomjs-launcher'
],
preprocessors: {
"**/*.handlebars": 'ember'
}
});
};
Now that we have the Karma configuration setup for integration testing, add a new file named integration_tests.js under the tests folder. Inside this folder we need to add a simple test to prove we can stand up the entire Ember.js application without error. Add a simple qunit test to see if we can hit the '/' route and get the basic HTML returned. For the initial test, we are only asserting that the table tag exists in the HTML that was generated.
test('hello world', function() {
App.reset();
visit("/").then(function() {
ok(exists("table"));
});
});
Notice we are using a few helpers that are built into ember-testing like visit and find. The visit helper is an ember friendly way of telling the application what state to be at during the execution. This test starts at the '/' route because that is where the People models get bound to the template and our HTML table is generated. The find helper is a quick way to lookup elements in the DOM using CSS selectors like you would with jQuery to verify something about the markup.
Before we can run this test we need to add a test helper file that will inject the test helpers and set a generic root element. Add the code below, to a file named integration_test_helper.js in the same tests directory. This will ensure our application has the test helpers at execution time.
document.write('<div id="ember-testing-container"><div id="ember-testing"></div></div>');
App.rootElement = '#ember-testing';
App.setupForTesting();
App.injectTestHelpers();
function exists(selector) {
return !!find(selector).length;
}
Now from the command line you should be able to execute the integration test above. If you got a passing test, remove the table from the handlebars template to make it fail (just to help prove Ember was generating the HTML using that template).
Now that we have the integration tests setup, it's time to write the one that asserts we show each user's fullName instead of their firstName. We want to first assert that we get two rows, one for each person.
test('hello world', function() {
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, rows);
});
});
Note: The application is currently returning hard coded data to keep everything simple at the moment. If you are curious why we get two people, here is the find method on the model:
App.Person.reopenClass({
people: [],
find: function() {
var first = App.Person.create({firstName: 'x', lastName: 'y'});
var last = App.Person.create({firstName: 'x', lastName: 'y'});
this.people.pushObject(first);
this.people.pushObject(last);
return this.people;
}
});
If we run the tests now, we should still have everything passing because two people are returned as we would expect. Next, we need to get the table cell that shows the person's name and assert it's using the fullName property instead of just firstName.
test('hello world', function() {
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, rows);
var fullName = find("table tr:eq(0) td:eq(0)").text();
equal(fullName, "x y", "the first table row had fullName: " + fullName);
});
});
If you run the above test you should see a failing test because we haven't yet updated the template to use fullName. Now that we have a failing test, update the template to use fullName and run the tests using ./node_modules/karma/bin/karma start. You should now have a passing suite of both unit and integration tests.
If you are asking yourself, "when should I write a unit test vs. an integration test?", the answer is simply: what will be less painful? If writing a unit test is faster and it explains the problem better than a much larger integration test, then I say write the unit test. If the unit tests seem less valuable because you are doing basic CRUD and the real behavior is in the interaction between components, I say write the integration test. Because the integration tests written with ember-testing are blazingly fast, they are part of the developer feedback cycle and should be used similarly to a unit test when it makes sense.
To show a CRUD like integration test in action, write the following test to prove the add button puts the person into the collection and that a new row gets rendered in the handlebars template.
test('add will append another person to the html table', function() {
App.Person.people = [];
App.reset();
visit("/").then(function() {
var rows = find("table tr").length
equal(rows, 2, "the table had " + rows + " rows");
fillIn(".firstName", "foo");
fillIn(".lastName", "bar");
return click(".submit");
}).then(function() {
equal(find("table tr").length, 3, "the table of people was not complete");
equal(find("table tr:eq(2) td:eq(0)").text(), "foo bar", "the fullName for the person was incorrect");
});
});
Start by telling the test what state you want to work with, then using the fillIn helper, add a first name and last name. Now if you click the submit button it should add that person to the HTML table, so in the returning then we can assert that three people exist in the HTML table. Run this test and it should fail because the Ember controller isn't complete.
To get the test passing, add the following line to the PeopleController
App.PeopleController = Ember.ArrayController.extend({
actions: {
addPerson: function() {
var person = {
firstName: this.get('firstName'),
lastName: this.get('lastName')
};
App.Person.add(person);
}
}
});
Now if you run the tests using ./node_modules/karma/bin/karma start it should show three people in the rendered HTML.
The last test is the delete, notice we find the button for a specific row and click it. In the following then we simply verify one less person is shown in the HTML table.
test('delete will remove the person for a given row', function() {
App.Person.people = [];
App.reset();
visit("/").then(function() {
var rows = find("table tr").length;
equal(rows, 2, "the table had " + rows + " rows");
return click("table .delete:first");
}).then(function() {
equal(find("table tr").length, 1, "the table of people was not complete
});
});")})})
To get this passing, simply add the following line to the PeopleController:
App.PeopleController = Ember.ArrayController.extend({
actions: {
addPerson: function() {
var person = {
firstName: this.get('firstName'),
lastName: this.get('lastName')
};
App.Person.add(person);
},
deletePerson: function(person) {
App.Person.remove(person);
}
}
});
Run the tests from the command line and you should once again have a passing suite of tests.
So that wraps up our sample application. Feel free to ask any questions down in the comments.
If you prefer to use Grunt instead of the karma-ember-preprocessor, simply remove the plugins and preprocessors configuration. Also remove templates/*.handlebars from the files section as Karma won't need to precompile the templates. Here is a simplified karma.conf.js that works when using grunt to precompile the handlebars templates.
module.exports = function(karma) {
karma.set({
basePath: 'js',
files: [
"lib/deps.min.js", //built by your grunt task
"tests/*.js"
],
logLevel: karma.LOG_ERROR,
browsers: ['PhantomJS'],
singleRun: true,
autoWatch: false,
frameworks: ["qunit"]
});
};
And that's it!
]]>