feat(nodecli): リファクタリングとユニットテストのセクション #226
Conversation
|
@azu 時間あるときに見てもらっても良いですか？ |
| }; | ||
| ``` | ||
|
|
||
| このようにエクスポートされたモジュールは、`require`関数によってインポートされます。 |
| ## ユニットテスト実行環境を作る | ||
|
|
||
| ユニットテストの実行にはさまざまな方法がありますが、 | ||
| このセクションではテスティングフレームワークとして[Mocha][]を使って、ユニットテストの実行環境を作成します。 | ||
| Mochaの詳細については、[JavaScript Promiseの本][]よりテストの章を参照してください。 |
There was a problem hiding this comment.
Promise本ってここに書いてある情報と大差ない気がする( 非同期ぐらい?) ので、ここにそのまま書いていいんじゃないかなーといいう気がした。
- Mochaはグローバルにit関数などテスト用の関数を定義している
- テストは
mochaコマンドを使って実行する - テストのアサーション自体はMochaとは別でここではNode.jsのコアライブラリであるassertモジュールを使う(ここの説明がちょっと面倒そうだけどちょこちょこ見る説明かも
- assert単独の動作を見てからMocha? (一緒でも良い気はするけど)
There was a problem hiding this comment.
他の事例を見てきたけど次みたいな流れだった
-
assert単体でのテストの話
-
テストフレームワークを使うと次のような利点があるよ
テストのグループ化
テスト結果出力のカスタマイズ
テスト毎のライフサイクル
非同期処理に対するテストのサポート -
mocha有名なのでmochaを使うよ
-
mochaはassertを自由に選べるので今回は引き続きassertを使うよ
という感じだった。
There was a problem hiding this comment.
Backbone.js TestingだとなぜMocha?みたいな話は欄外だった。
| @@ -4,11 +4,127 @@ author: laco | |||
|
|
|||
| # ユニットテストを記述する | |||
|
|
|||
| このセクションでは、これまで作成したCLIアプリケーションにユニットテストを導入します。 | |||
| ユニットテストを導入するためには、ソースコードを整理してテスト可能な状態にリファクタリングする必要があります。 | |||
There was a problem hiding this comment.
リファクタリングといいつつ構造が変わる気がするので、
テストがしやすくなるようにモジュール化します。 的な感じでいいんじゃないかな。
|
|
||
| ```json | ||
| { | ||
| "scripts": { |
There was a problem hiding this comment.
これ前後に devDepsとかは実際にはあるので、 ... みたいな省略表示して方がいいのかな?
(シンタックスがあれだけど…)
| 今回のアプリケーションでは、CLIアプリケーションとしてコマンドライン引数を処理する部分と、MarkdownをHTMLへ変換する部分に分割します。 | ||
|
|
||
| Node.jsでは、複数のJavaScriptファイル間で変数や関数などをやりとりするために、モジュールという仕組みを利用します。 | ||
| モジュールはあるJavaScritpファイル中でエクスポートされ、別のファイルからインポートされます。 |
There was a problem hiding this comment.
何か微妙な違和感がある。
モジュールはファイルそのものを表すような気がする?
- Aがモジュール
- Aは機能(関数や値)をexportする
- BからAモジュールをimportする
- importしたAモジュールの機能を利用する
この文だとAが複数のモジュールをexportしてるような感じがする?
イマイチどっちが正しいか分かってないけど、ECMAScript的には
Script (<script>)と Module(<script type="module">)で、moduleはbindingをexportするみたいな感じになる気がする。
なので、ファイルからexportするのは変数や関数で、モジュールはそういうことをするファイルそのものという形になるんじゃなかな。
|
@azu モジュールとファイルの関係のあたりレビューしてもらってよいですか |
| greet("World"); // => Hello World! | ||
| ``` | ||
|
|
||
| `module.exports`オブジェクトに直接代入するのではなく、そのプロパティとしてオブジェクトをエクスポートすることもできます。 |
There was a problem hiding this comment.
そのプロパティとしてオブジェクトをエクスポートすることもできます。
エクスポートできるのはオブジェクト以外にもプリミティブな値もできるので、
そのプロパティとして任意の値をエクスポートすることもできます。
とかそんな感じ?
| ## ユニットテストを記述する | ||
|
|
||
| テストの実行環境ができたので、実際にユニットテストを記述します。 | ||
| Mochaのユニットテストは`test`ディレクトリの中にJavaScriptファイルを配置して記述します。 | ||
| `test/md2html.js`ファイルを作成し、`md2html.js`に対するユニットテストを次のように記述します。 |
There was a problem hiding this comment.
テストのファイル名 同じ名前にするか md2html-test.js みたいにするか悩みどころな感じがする(普段は後者を選ぶけど)
| 今回は変換元のMarkdownファイルと、期待する変換結果のHTMLファイルの2つが存在します。 | ||
|
|
||
| `assert`関数は、Node.jsの標準モジュールのひとつである[assertモジュール][]から提供される関数です。 | ||
| この関数は引数の評価結果がfalseであるとき、実行時にエラーを発生します。 |
There was a problem hiding this comment.
実行時にエラーを発生します
実行時にエラーが発生します or 実行時にエラーを投げます
|
|
||
| `assert`関数は、Node.jsの標準モジュールのひとつである[assertモジュール][]から提供される関数です。 | ||
| この関数は引数の評価結果がfalseであるとき、実行時にエラーを発生します。 | ||
| Mochaの`it`関数はその内部でエラーが発生したとき、そのテストを失敗として扱います。 |
There was a problem hiding this comment.
これを先に書いて、次みたいにするのもありかなー
assertとテストの正否の関係が少しだけ唐突な感じがした。
Mochaの
it関数はその関数内でエラーが発生したとき、そのテストを失敗として扱います。
つまり、期待する変換結果と異なるならエラーを投げ、期待通りならエラーを投げないというテストコードを書けば良いことがわかります。（ここ冗長なので手直し必要）
今回はNode.jsの標準モジュールのひとつであるassertモジュールを利用します。
この関数は引数の評価結果がfalseであるとき、実行時にエラーを投げます。
ちょっと冗長っぽい感じもする
|
|
||
| [moduleオブジェクト]: https://nodejs.org/api/modules.html#modules_the_module_object | ||
| [Mocha]: http://mochajs.org/ |
There was a problem hiding this comment.
リポジトリのリンクはsになってたので一応
|
だいたいいいかなって感じになった |
|
一部テストできてなかったので修正した 61f21ec |
#7