Page 12 - MSDN Magazine, November 2018

The Working Programmer TED NEWARD How To Be MEAN: Testing Angularly
Welcome back again, MEANers.
With any luck, the “debate” around unit testing of code no longer
requires discussion—as a developer, you should be looking for ways to automate the testing code you write, without question. Arguments may continue as to whether those tests should come before or after the code in question, perhaps, but it’s pretty clear that tests are not an optional part of a modern software project anymore. Which then, of course, raises the question: How do you test an Angular application? I touched briefly on the test files, back in the May 2017 issue when I first started building out some Angular components, but it was hardly expansive (msdn.com/magazine/mt808505). Now it’s time to take a deeper look.
Back to Beginnings
Let’s take a step back to the beginning of the application. When “ng new” is run to scaffold out the initial stages of the application, it creates all the necessary tools and hooks and files in place to ensure that the application can be tested. In fact, immediately after “ng new,” without making even a single change to any file, you can run “ng test” to run the test runner, which in turn executes the code written against the test framework code scaffolded out.
As a developer, you should be looking for ways to automate the testing code you write, without question.
When run, “npm test” fires up Karma, the test runner, which then fires up a browser instance and runs the tests inside that instance. Karma continues to run, keeping an open WebSocket to the browser so that any changes to the source files can be immedi- ately tested, removing some of the overhead of testing and bringing us closer to a no-wait code-and-test cycle. The project scaffolding provides three tests, encoded in the “app.component.spec.ts” file, which tests the corresponding “app.component.ts” code. As a general rule, each component in the Angular application should have a corresponding “.spec.ts” file to hold all the tests. If each component is created by the Angular CLI, it will usually generate a corresponding test file, with a few exceptions (such as “class”)
that will require a “--spec" argument to the “generate” command to create the spec (short for “specification”) file.
As a matter of fact, let’s generate a quick class, Speaker (of course), and then write some tests for it. As usual, create the component with the Angular CLI (“ng generate class Speaker --spec”), and edit the “speaker.ts” file to contain a simple class with five constructor public properties:
export class Speaker { constructor(public id: number,
public firstName: string, public lastName: string, public age: number, public bio?: string,
) {}
}
The corresponding tests should exercise the various properties to ensure they work as expected:
import { Speaker } from './speaker';
describe('Speaker', () => {
it('should create an instance', () => {
expect(new Speaker(1, "Ted", "Neward", 47, "Ted is a big geek")).toBeTruthy(); });
it('should keep data handy', () => {
var s = new Speaker(1, "Ted", "Neward", 47, "Ted is a big geek"); expect(s.firstName).toBe("Ted"); expect(s.firstName).toEqual("Neward"); expect(s.age).toBeGreaterThan(40);
}) });
As the class gets more complicated, more complex tests should be added, as well. Much of the power of the testing lies in the “expect” framework, which provides a large number of “toBe” methods to test various scenarios. Here you see several flavors of this, including “toEqual,” which does an equality test, and “toBeGreaterThan,” which does exactly as its name implies.
But those of you who are following along at home, however, will see something is wrong—after the spec file is saved, the open browser instance turns an ugly shade of red, pointing out that “Ted” is not the same as “Neward”! Sure enough, there’s a bug in the second “expect” statement, looking to compare “firstName” when it should be “lastName.” This is good, because while test code is testing for bugs in code, it’s also the case that sometimes the bug is in the test, and getting that feedback as soon as you write the test helps avoid test bugs.
More Tests
Of course, an Angular app is made up of more than simple classes; it also may include services, which are generally pretty simple to
8 msdn magazine