お帰りなさい｡
では､ 最初のテストを書いてみましょう｡
このプログラムの中で実行するのは､ 簡単な関数だけにしておきます｡
メインファイルの中に､ 例えばこれをもう少し大きくしてみようというものを作ってみます｡
ここでは､ do stuffという関数があるとする｡
はい､ とてもわかりやすい機能です｡
さて､ ここでは「数字を受け入れる」ということにしておきます｡
そして､ 単純にnum＋5を返すだけです｡
とてもとてもシンプルな機能です｡
例えば､ これがアプリをビルドするコードだとします｡
つまり､ これはひとつの機能に過ぎないのです｡
しかし､ 仮にテストしたい関数がたくさんあったとして､ それらは私たちのコードで実行されるアクションである｡
だから単体テストのやり方は
という感じです｡
テストファイルを持っていて､ ユニットテストをインポートした後､ テストしたいファイル（ここではmain
py）をインポートします｡
だから､ 輸入しよう｡
メイン
どちらが正しいかというと､ ここです｡
あるいは､ 必要であれば､ 関数もインポートすればよい｡
しかし､ 私たちの場合､ 仮にここに多くの関数があるので､ mainをインポートして､ そこで利用できるすべての関数を利用することができます｡
さて､ ユニットテストの仕組みは､ クラスを作り､ それに好きな名前を付けるというものです｡
そして､ ここですべてのテストを行います｡
だから､ テストメインということにしておこう｡
そして､ このクラスの内部で､ ユニットテストが提供するテストを継承しています｡
つまり､ これはユニットテストの標準的な作業方法に過ぎないのです｡
つまり､ ユニットテストのテストケースを継承し､ その機能をテストのメインクラスで利用できるようにしたわけです｡
ここで､ テストを開始し､ テストするためのコードを書くことができます｡
では､ どのようにすればmainをテストできるのでしょうか？
機能すること｡
これはクラスの一部なので､ ここに関数やメソッドを書いて､ 「テストをしたいんだけど､
どうすればいい？
そして､ ここで自己を受け取ることになる｡
ここで､ コードをテストして､ ここにある数字が10に等しければ､ 乱数を与えただけだと言えるでしょう｡
それから､ resultがmain dot do stuffに等しくなると言うことです｡
つまり､ do stuffはMaineから来るということを忘れないでください｡
そこで､ do stuff関数を実行し､ ここでパラメータnumを与えます｡ これは今あげたもので､ テストパラメータと呼ぶことにしましょう｡
このテストパラメータで､ コードを実行し､ 結果を得るわけです｡
そして､ この最後の一行がユニットテストの重要な部分です｡
ユニットテストでは､ セルフドット､ アサートイコール､ アサートイコールは､ ユニットテストから継承したときに得られるもので､
アサートイコールは､ おいアサートと言います｡
または､ この2つのパラメータが等しいことを確認する｡
この場合､ 結果がまあ､ 10に等しいかどうかをテストしたい｡
プラス5で15になるはずです｡
わかりました｡
さて､ 最後にこの中で､ ユニットテストを実行するだけです｡
そして､ ユニットテストの実行方法ですが､ これは私が行った1つのテストに過ぎませんから｡
複数のテストを行うことができた｡
必要なのは､ unit test dot main と言うだけです｡
これは､ テストメイン内のテストファイル全体を実行します｡
今これを実行すると､ Python 3とコマンドラインからTest dot piと言うだけでいいんです｡
そして､ 私は得る｡
OCは､ よく超高速で0秒で1つのテストを実行しました｡
いい感じで早かったですね｡
ここで､ 「これは10に等しい」と主張する別のことをするとしよう｡
これを実行すると
あれを見てください｡
失敗した？
失敗とは？
まあ､ 機能をやるためのテストは失敗したんですけどね｡
8行目に
つまり､ ここでアサーションエラーが発生しているのです｡
15個になったが､ 10個を想定していた｡
なんてかっこいいんでしょう｡
というわけで､ 現在1つの失敗があるので､ コードを修正する必要があります｡
だから､ 何かがおかしいんです｡
さて､ 私の場合ですが､ これは断言したからです｡
B 15の答えです｡
しかし､ ここに別のテストを作ったらどうでしょう？
と確認する｡
おい､ 俺たちもテストがあったらどうするんだ｡
そして､ 今回のテストプログラムは､ 実は糸になるんです｡
では､ この関数に何をさせたいのか｡
まあ､ 私たちの場合､ 多分､ エラー､ 多分､ 値のエラーが出ます｡
だから､ バリューとしか言いようがない｡
だって､ これじゃダメなんだもん｡
今､ これを実行したら､ クリアしよう｡
今､ これを実行すると
では､ 2つのテストを行います｡
でも､ 相続人が一人いるのですが､ ここで､ おい､ タイパーは文字列の連結しかできないぞ､ 8個じゃないぞ､
という相続人が出てきているのがわかります｡
さて､ この場合､ 実際に何が失敗したのでしょうか？
今やったことは､ 実際には機能的に失敗しているので､ テストファイルです｡
でも､ すぐにでも｡
なるほど､ そうなんですね｡
わかりました｡
これは修正する必要がありますから､ メインに戻って､ どんなエラーも見逃さないようにしたいと思います｡
型エラーや値エラーのように｡
だから､ まずできることは､ Aren'tと言うだけです｡
番号です｡
そして､ それを保存して､ 何かを整数に変換することを確認し､ これを実行します｡
さて､ 今度はvalue literalでvalue errorが発生したので､ この文字列の一部では実行できません｡
さて､ コードを改善するもう一つの方法は､ try except block writeでラップして､ catchすることです｡
では､ 以外と言いましょう｡
そして､ この中で､ 値のエラーを受け入れる｡
そして､ エラーとして言いましょう｡
そしてここでは､ やりたいことが何でもできる｡
だから､ エラーが欲しければ戻せばいいし､ 空気を上げることもできる｡
私たちの場合は､ 空気を返せばいいんです｡
その理由は､ すぐにお見せします｡
さて､ これを実行したら｡
私のテストが失敗しているのがわかりますが､ 今は実際にアサーション・エラーになっています｡
アサーション・エラーはこちらのテスト・ファイルから発生しており､ 「結果と値のエラーが等しいことを確認したい」とアサーションしています｡
ここで､ 少しミスマッチがあることがお分かりいただけると思います｡
こちらの値では､ クラスの値と一致しないエラーが発生しています｡
さて､ これはちょっとしたトリックで､ エラーを返しているためです｡
実はこれ､ バリューエランクラスのインスタンスなんです｡
そこで､ このような工夫が必要なのです｡
私たちは､ ちょっと､ インスタンスです､ と言う必要があります｡
そして､ 「それは何の例なのか」と言いなさい｡
さて､ 結果はこのようなバリューエラーの例となるのでしょうか｡
しかし､ ここで問題なのは
これをもう少し大きくしようということです｡
ここで問題なのは､ assert equalsが2つのパラメータ､ つまり等しくなければならない2つのものを期待しようとしていることである｡
しかし､ ここでは､ これが真を返すこと､ つまり結果が値エラーのインスタンスであることを確認したいだけです｡
では､ どうすればいいのか？
アサートイコール以外にも､ ユニットテストが提供するいくつかのメソッドがあります｡
このユニットテストのドキュメントを見ると､ 1行目にアサートメソッドのリストが書いてありますね｡
つまり､ これらはすべてコードのアサーションとテストのためのメソッドであることがわかります｡
おそらく私たちが欲しいのは､ このアサートトゥルーの方だと思います｡
何かが真実であるかどうかを確認すること｡
だから､ もし私がアサートしたら｡
これが事実であること｡
そして､ 私はテストを実行しました｡
これをクリアして､ もう一度テストを実行してみましょう｡
これでよしとする｡
2つのテストを行いましたが､ すべて問題ないようです｡
そして､ もう一度､ このことを確認することです｡
これはなぜでしょうか｡
さて､ テストファイルを実行しています｡
そして､ テストを実行し､ 大丈夫そうなことをやってみる｡
次に､ テストパラメータを本当に必要でないもの､ つまり単なる文字列にする第2部を行います｡
その結果､ このエラーを捕捉したので､ 値のエラーが返されることになるのです｡
そして最後に､ このコード片を実行します｡
ねえ､ これって本当なの？
結果は値のエラーになるのでしょうか？
だから､ 私たちがここで何をしているのかがわかるでしょう｡
私たちがテストでやろうとしていることは､ 単純に機能を壊してみることで､ 機能を改善することです｡
そこで､ この関数を壊して､ 「この関数を騙して空気を送り出すことはできないか？
そして､ 一度そうしてテストが失敗したら､ 関数に戻って修正しようとするのです｡
私たちがここでやったようなことは､ 本当に､ 本当にクールなことです｡
これは､ テストではよくあることで､ まあ､ 機能が完璧になるまで壊してみるということです｡
さて､ ここでじっくりとこの関数を壊せるかどうか､ そして次のビデオではさらにいくつかのテストを加えてみてください｡
この機能をより良いものにするために､ もう少し付け加えようと思っています｡
次回作でお会いしましょう｡