docs(testing): fix typos, exclude node_modules from tsconfig (#763)

closes #723
This commit is contained in:
Jason Zhekov 2016-01-19 11:15:26 +02:00 committed by Ward Bell
parent 6e11cf6a1e
commit 59dd4b0c2c
2 changed files with 38 additions and 35 deletions

View File

@ -1,7 +1,7 @@
include ../../../../_includes/_util-fns include ../../../../_includes/_util-fns
:marked :marked
In this chapter well setup the environment for testing our sample application and write a few easy Jasmine tests of the apps simplest parts. In this chapter we'll setup the environment for testing our sample application and write a few easy Jasmine tests of the app's simplest parts.
We'll learn: We'll learn:
- to test one of our application classes - to test one of our application classes
- why we prefer our test files to be next to their corresponding source files - why we prefer our test files to be next to their corresponding source files
@ -44,14 +44,14 @@ include ../../../../_includes/_util-fns
</html> </html>
``` ```
Were picking up right where we left off. All weve done is change the title. We're picking up right where we left off. All we've done is change the title.
.l-main-section .l-main-section
:marked :marked
## Update `package.json` for testing ## Update `package.json` for testing
Well assume that the application has `package.json` file that looks more or less like We'll assume that the application has `package.json` file that looks more or less like
the one we prescribed in the in the “Install npm packages locally” section of the the one we prescribed in the in the "Install npm packages locally" section of the
[QuickStart](../quickstart.html). [QuickStart](../quickstart.html).
We must install the Jasmine package as well: We must install the Jasmine package as well:
@ -62,7 +62,7 @@ pre.prettyprint.lang-bash
.alert.is-important Be sure to install <code>jasmine-core</code> , not <code>jasmine</code>! .alert.is-important Be sure to install <code>jasmine-core</code> , not <code>jasmine</code>!
:marked :marked
Lets make one more change to the `package.json` script commands. Let's make one more change to the `package.json` script commands.
**Open the `package.json` ** and scroll to the `scripts` node. Look for the command named `test`. Change it to: **Open the `package.json` ** and scroll to the `scripts` node. Look for the command named `test`. Change it to:
@ -96,16 +96,16 @@ pre.prettyprint.lang-bash
} }
``` ```
Lets add a couple of simple tests in the `<body>` element. Let's add a couple of simple tests in the `<body>` element.
First, well load the JavaScript file that defines the `Hero` class. First, we'll load the JavaScript file that defines the `Hero` class.
``` ```
<!-- load the application's Hero definition --> <!-- load the application's Hero definition -->
<script src="app/hero.js"></script> <script src="app/hero.js"></script>
``` ```
Next, well add an inline script element with the `Hero`tests themselves Next, we'll add an inline script element with the `Hero`tests themselves
``` ```
<script> <script>
@ -126,7 +126,7 @@ pre.prettyprint.lang-bash
</script> </script>
``` ```
Thats the basic Jasmine we learned back in “Jasmine 101”. That's the basic Jasmine we learned back in "Jasmine 101".
Notice that we surrounded our tests with ** `describe('Hero')` **. Notice that we surrounded our tests with ** `describe('Hero')` **.
@ -152,13 +152,13 @@ figure.image-display
:marked :marked
## Critique ## Critique
Is this `Hero` class even worth testing? Its essentially a property bag with almost no logic. Maybe we should have tested the cloning feature. Maybe we should have tested id generation. We didnt bother because there wasnt much to learn by doing that. Is this `Hero` class even worth testing? It's essentially a property bag with almost no logic. Maybe we should have tested the cloning feature. Maybe we should have tested id generation. We didn't bother because there wasn't much to learn by doing that.
Its more important to take note of the `//Demo only` comment in the `unit-tests.html`. It's more important to take note of the `//Demo only` comment in the `unit-tests.html`.
** Well never write real tests in the HTML this way**. Its nice that we can write *some* of our application tests directly in the HTML. But dumping all of our tests into HTML is not sustainable and even if we didnt mind that approach, we could only test a tiny fraction of our app this way. ** We'll never write real tests in the HTML this way**. It's nice that we can write *some* of our application tests directly in the HTML. But dumping all of our tests into HTML is not sustainable and even if we didn't mind that approach, we could only test a tiny fraction of our app this way.
We need to relocate these tests to a separate file. Lets do that next. We need to relocate these tests to a separate file. Let's do that next.
.l-main-section .l-main-section
:marked :marked
@ -173,9 +173,9 @@ figure.image-display
- When we move the source (inevitable), we remember to move the test. - When we move the source (inevitable), we remember to move the test.
- When we rename the source file (inevitable), we remember to rename the test file. - When we rename the source file (inevitable), we remember to rename the test file.
We cant think of a downside. The server doesnt care where they are. They are easy to find and distinguish from application files when named conventionally. We can't think of a downside. The server doesn't care where they are. They are easy to find and distinguish from application files when named conventionally.
You may put your tests elsewhere if you wish. Were putting ours inside the app, next to the source files that they test. You may put your tests elsewhere if you wish. We're putting ours inside the app, next to the source files that they test.
.l-main-section .l-main-section
:marked :marked
@ -183,7 +183,7 @@ figure.image-display
**Create** a new file, ** `hero.spec.ts` ** in `src/app` next to `hero.ts`. **Create** a new file, ** `hero.spec.ts` ** in `src/app` next to `hero.ts`.
Notice the “.spec” suffix in the test files filename, appended to the name of the file holding the application part were testing. Notice the ".spec" suffix in the test file's filename, appended to the name of the file holding the application part we're testing.
.alert.is-important All of our unit test files follow this .spec naming pattern. .alert.is-important All of our unit test files follow this .spec naming pattern.
@ -208,13 +208,13 @@ figure.image-display
``` ```
### Import the part were testing ### Import the part we're testing
During our conversion to TypeScript, we added an `import {Hero} from './hero' ` statement. During our conversion to TypeScript, we added an `import {Hero} from './hero' ` statement.
If we forgot this import, a TypeScript-aware editor would warn us, with a squiggly red underline, that it cant find the definition of the `Hero` class. If we forgot this import, a TypeScript-aware editor would warn us, with a squiggly red underline, that it can't find the definition of the `Hero` class.
TypeScript doesnt know what a `Hero` is. It doesnt know about the script tag back in the `unit-tests.html` that loads the `hero.js` file. TypeScript doesn't know what a `Hero` is. It doesn't know about the script tag back in the `unit-tests.html` that loads the `hero.js` file.
### Update unit-tests.html ### Update unit-tests.html
@ -231,9 +231,9 @@ figure.image-display
img(src='/resources/images/devguide/first-app-tests/Jasmine-not-running-tests.png' style="width:400px;" alt="Jasmine not running any tests") img(src='/resources/images/devguide/first-app-tests/Jasmine-not-running-tests.png' style="width:400px;" alt="Jasmine not running any tests")
:marked :marked
Thats Jasmine saying “**things are _so_ bad that _Im not running any tests_.**” That's Jasmine saying "**things are _so_ bad that _I'm not running any tests_.**"
Open the browsers Developer Tools (F12, Ctrl-Shift-i). Theres an error: Open the browser's Developer Tools (F12, Ctrl-Shift-i). There's an error:
code-example(format="" language="html"). code-example(format="" language="html").
Uncaught ReferenceError: exports is not defined Uncaught ReferenceError: exports is not defined
@ -244,10 +244,10 @@ code-example(format="" language="html").
The immediate cause of the error is the `export` statement in `hero.ts`. The immediate cause of the error is the `export` statement in `hero.ts`.
That error was there all along. That error was there all along.
It wasnt a problem until we tried to `import` the `Hero` class in our tests. It wasn't a problem until we tried to `import` the `Hero` class in our tests.
Our test environment lacks support for module loading. Our test environment lacks support for module loading.
Apparently we cant simply load our application and test scripts like we do with 3rd party JavaScript libraries. Apparently we can't simply load our application and test scripts like we do with 3rd party JavaScript libraries.
We are committed to module loading in our application. We are committed to module loading in our application.
Our app will call `import`. Our tests must do so too. Our app will call `import`. Our tests must do so too.
@ -301,25 +301,25 @@ figure.image-display
### System.config ### System.config
System.js demands that we specify a default extension for the filenames that correspond to whatever it is asked to import. System.js demands that we specify a default extension for the filenames that correspond to whatever it is asked to import.
Without that default, it would translate an import statement such as `import {Hero} from ./here` to a request for the file named `hero`. Without that default, it would translate an import statement such as `import {Hero} from './hero'` to a request for the file named `hero`.
Not `hero.js`. Just plain `hero`. Our server error with “404 - not found” because it doesnt have a file of that name. Not `hero.js`. Just plain `hero`. Our server error with "404 - not found" because it doesn't have a file of that name.
Once configured with a default extension of js,&nbsp; Systemjs requests `hero.js` which *does* exist and is promptly returned by our server. Once configured with a default extension of 'js',&nbsp; Systemjs requests `hero.js` which *does* exist and is promptly returned by our server.
### Asynchronous System.import ### Asynchronous System.import
The call to `System.import` shouldnt surprise us but its asynchronous nature might. The call to `System.import` shouldn't surprise us but it's asynchronous nature might.
If we ponder this for a moment, we realize that it must be asynchronous because If we ponder this for a moment, we realize that it must be asynchronous because
System.js may have to fetch the corresponding JavaScript file from the server. System.js may have to fetch the corresponding JavaScript file from the server.
Accordingly, `System.import` returns a promise and we must wait for that promise to resolve. Accordingly, `System.import` returns a promise and we must wait for that promise to resolve.
Only then can Jasmine start evaluating the imported tests. Only then can Jasmine start evaluating the imported tests.
### window.onload ### window.onload
Jasmine doesnt have a `start` method. It wires its own start to the browser windows `load` event. Jasmine doesn't have a `start` method. It wires its own start to the browser window's `load` event.
That makes sense if were loading our tests with script tags. That makes sense if we're loading our tests with script tags.
The browser raises the `load` event when it finishes loading all scripts. The browser raises the `load` event when it finishes loading all scripts.
But were not loading test scripts inline anymore. But we're not loading test scripts inline anymore.
Were using the systemjs module loader and it wont be done until long after the browser raised the `load` event. We're using the systemjs module loader and it won't be done until long after the browser raised the `load` event.
Meanwhile, Jasmine started and ran to completion … with no tests to evaluate … before the import completed. Meanwhile, Jasmine started and ran to completion … with no tests to evaluate … before the import completed.
So we must wait until the import completes and only then call the window `onLoad` handler. So we must wait until the import completes and only then call the window `onLoad` handler.
@ -327,10 +327,10 @@ figure.image-display
.l-main-section .l-main-section
:marked :marked
## Whats Next? ## What's Next?
We are able to test a part of our application with simple Jasmine tests. We are able to test a part of our application with simple Jasmine tests.
The part was a stand-alone class that made no mention or use of Angular. The part was a stand-alone class that made no mention or use of Angular.
Thats not rare but its not typical either. Most of our application parts make some use of the Angular framework. That's not rare but it's not typical either. Most of our application parts make some use of the Angular framework.
In the [next chapter](testing-an-angular-pipe.html), well test a class that does rely on Angular. In the [next chapter](testing-an-angular-pipe.html), we'll test a class that does rely on Angular.

View File

@ -114,7 +114,10 @@ figure.image-display
"sourceMap": true, "sourceMap": true,
"emitDecoratorMetadata": true, "emitDecoratorMetadata": true,
"experimentalDecorators": true "experimentalDecorators": true
} },
"exclude": [
"node_modules"
]
} }
``` ```
## Compile and Run ## Compile and Run