お帰りなさい｡
続いてユニットテストについて説明します｡
さて､ ここで一つ気づいたのですが､ ドキュメントを見ると､ 実はassert isのインスタンスがあるんですね｡
つまり､ assert trueと言う代わりに､
assert as instanceを使うことができるのです｡
というわけで､ 私の場合､ これをassert as instanceに変更して解決しましょう｡
こんな感じ｡
だから､ ちょっとだけキレイに｡
これがうまくいくかどうか見てみましょう｡
わかりました｡
すべて順調です｡
では､ もう一度､ コードを壊してみましょう｡
だから､ すべてが順調なのです｡
でも､ 違うことをしたらどうだろう？
もし､ そうなったら？
例えば､ 別のテストを追加して､ testとしましょう｡
いろいろやってください｡
通常､ これらの関数にはもっと良い名前を付けて､ より分かりやすくしたいものです｡
でも､ 私たちの場合は､ 今回､ どのように動くかを確認するためなので､ これでいいんです｡
テストラムがイコールになるようにやってみましょう｡
なしはどうでしょうか？
では次に､ これを実行すると､ このコードをもう一度実行してみましょう｡
ところで､ テストの中でコードをコピーしていることにお気づきでしょうか｡ 「もっとシンプルにできないかな？
そして､ 自分たちを繰り返さないこと｡
そうすれば､ もっと簡単にできるようになりますよ｡
しかし､ テストとなると､ 本番には出ず､ これはあくまで開発用なので､
他の人が自分のテストを理解するために､ 読みやすいテストがどうしても必要です｡
なぜなら､ テストをする際には､ 読みやすさが本当に､ 本当に重要だからです｡
私たちは､ 同じことを繰り返さないことや､ コードを効率的に､ 素敵に､ 小さくすることをそれほど気にしていません｡
だから､ 私は､ 本当に説明的で､ 本当に明白なテストを書くのが好きです｡
ここでは､ self､ dot､ assert equal､ andとしましょう｡
うーん､ これはどうしたらいいんだろう？
まあ､ この場合､ バリューエラーを期待しているのですが｡
では､ こうしてみましょう｡
その結果､ バリューエラーになることを期待しています｡
保存してテストを実行します｡
よし､ 空気を読もう｡
これは引数への型エラーと書かれています｡
文字列である必要があります｡
そして､ ノンタイプをあげています｡
わかりました｡
つまり､ これはint型では動作しないため､ 適切に処理されず､ 型エラーが発生するのです｡
では､ どうすればこれを解決できるのか｡
パラメータに型がない場合､ どのように調整すればよいのでしょうか？
さて､ まずはデフォルトのパラメータを与えてみましょう｡
仮にデフォルトのパラメータが0だとしよう｡
これを実行すると
もう一度｡
まだエラーが出ます｡
なるほど､ まだ直ってないんですね｡
引数は厳密なものでなければならない｡
非型ではなく､ オブジェクトや数値のようなバイ｡
だから､ まだ非タイプのチェックはしていない｡
そこでもうひとつ､ 私たちができることは､ こう言うことです｡
番号なら｡
つまり､ 数値の値を持っているかどうかをチェックしているわけです｡
覚えておいてほしいのですが､ これは何らかの数値やまあどんな値でもデフォルトでtrueになりますが､
非型の場合はfalseに変わります｡
つまり､ この中で､ もし番号があれば､ これを返すと言うことができます｡
Else.
そうでなければ､ また戻る｡
お願いします｡
番号を入力します｡
というのも､ このテストに数字を入力してくださいということで､ これを変更し､ assert
equalと言うことにします｡
その結果
になりそうです｡
番号を入力してください｡
今テストを実行すると､ これをクリアすることができます｡
おっとっと｡
0秒で2つのテストを実行したように見えますが､ 3つのテストがあり､ それが原因です｡
私にも同じ名前がついているのがおわかりいただけたでしょうか｡
同じ名前をつけても､ まあ､ どちらか一方しか動かないということをお忘れなく｡
そのため､ すべてのテスト名がユニークであることを確認します｡
だから､ これを実行するんです｡
わかりました｡
3つのテストを実行し､ すべて問題なく動作しています｡
とても､ かっこいいです｡
このように､ 非常に単純な関数から､ このようなエラーを検出するようになり､ 関数があまりにも単純で､
間違った入力を受け取った場合にどうなるかを理解するようになったのです｡
ようなものです｡
文字列または型でないもの｡
まあ､ そのとたんに機能が破綻したんですけどね｡
そこで､ テストを使い､ テストして壊していくことで､ この機能を改善することができたのです｡
そのため､ 耐久性が向上し､ 生産性にも優れています｡
そうだろ？
そして､ これこそがテストの力なのです｡
当初はこんなことは考えられなかったかもしれないので､ 間違いがないかを確認することができます｡
しかし､ コードと並行してテストを書くことで､ 機能を向上させることができました｡
さて､ 最後にもうひとつ付け加えておきたいことがあります｡
テストの上にもう一つ追加して､ テストパラメータが単なる空文字列であった場合の処理を行うようにしましょう｡
手に入れるべきです｡
番号を入力してください｡
だから､ これを実行したら
わかりました｡
4つのテストがパスしているので､ 我々のコードはうまく動いているようだ｡
さて､ ここで最後に､ いくつかのことを指摘しておきたいと思います｡
ユニットテストメインで電話をしているところです｡
しかし､ これは実際とは関係ない｡
ファイルです｡
私たちが書いたもの､ それがメインファイルです｡
仮にこれをリネームするとしたら､ デスクトップに移動してみましょう｡
そして､ これをこう変えたい､ と言う｡
スクリプト､ ドットパイ｡
では､ この私のケースをsublime textで開いてみましょう｡
ここに戻ろう｡
つまり､ メインのπはもう存在しないのです｡
保存してくださいということです｡
だから､ これはまったく別のファイルなんです｡
さて､ ここでscriptを行い､ 単純にすべてのインスタンスをscriptに変更すると｡
これを保存して､ 今､ 実行すると｡
このMainのユニットテストは､ 単純に､ すべてのテストをここで実行してください､ と言っています｡
もうひとつ､ これは以前にもお話したことですが､ このファイルがメインで実行されている場合は､ このファイルを実行すると言うことです｡
なぜなら､ test main などのファイルを他のファイルにインポートすることはあまりしたくないからです｡
これらは､ テストを実行するときにのみ実行されるべき個々のファイルです｡
だから､ ifアンダースコア､ アンダースコア名と言えばいいのです｡
イコールです｡
アンダースコア アンダースコア・メイン
次に､ このコードを実行してください｡
それで今､ これを保存して実行すると｡
これでよしとする｡
すべて順調です｡
しかし､ 今はこれがテストファイルであることを確認しています｡
そして､ このコードを実行するのは､ 実行されるファイルがメインである場合だけです｡
つまり､ これはユニットテストモジュールでユニットテストを行う標準的な方法なのです｡
一息ついて､ 次のビデオでテストについてもう少し詳しくお話ししましょう｡