お帰りなさい｡
以前書いたコードをもう一度見直して､ 楽しい練習をしてみましょう｡
1から10までの数字を当てる乱数当てゲームを覚えていますか？
このファイルを実行すると､ それが見えるか？
と聞かれました｡
では､ 1､ 2､ 3､ 4､ 5､ 6､ 7､ 8､ 9としましょう｡
そして､ ついにその番号を手に入れる｡
あなたは天才です｡
その数は9だった｡
では､ このコードをどのようにテストすればよいのでしょうか｡
さて､ ここで一つお気づきの点は､ 実際には関数を持っていないことです｡
そして､ 関数型プログラミングについて､ コードを小さな関数に分割することがいかに良いことか､
特に純粋な関数についてお話したことを思い出してください｡
このような考え方の大きなメリットのひとつは､ テストがとても簡単にできるコードを作成できることです｡
テストに複雑なロジックを入れる代わりに､ 関数に入力を与えて出力を期待するだけでよいのです｡
そして､ そのためにユニットテストがあるのです｡
そして､ ユニットテストの考え方は､ ユニットの各パーツをテストしているということです｡
これらのユニットテストは､ これらの単純な機能をテストする小さな小片です｡
そこで､ このコードを使って､ これを簡単な関数に分解してみるというのが､ 私の挑戦です｡
今すぐ
今回は､ 入力を受け取る推測の部分であるこの部分のみをテストしたいと思います｡
そして､ その推測を､ 私たちが持っているランダムな答えと照らし合わせると､ 何らかの出力が得られるはずです｡
だから､ どちらか一方を入力する｡
1から10まででなければならない｡
そして､ うまくいけば､ 文字列を手に入れることができるのです｡
しかし､ ここで重要なのは､ おそらくこれをテスト可能な関数に移動させたいということです｡
外界を無視することができる｡
そして､ これを独自の小さな機能に分割する｡
では､ ここでビデオを一時停止して､ 試してみてください｡
躓きもありますが､ テストに対する理解度が試されますね｡
ははは｡
面白いですね｡
あれはダジャレです｡
だから､ ビデオを一時停止して､ 試してみてください｡
そうでなければ､ さっさと答え合わせをする｡
まず最初に､ もう一度テストの設定をしたいと思います｡
ユニットテストをインポートして､ クラスtest mainを作成します｡
今回はテストスクリプトとでも言いましょうか､ テストゲームとでも言いましょうか｡
ユニットテストと言います｡
テストケース
これがテストケースとなる｡
そして､ ここで､ 例えば､ 簡単なテストを作成します｡
ゲームやテストの入力｡
自己を受け止める｡
とりあえず､ 何もしてないのでパスします
最後に､ もしもの時のために言っておきます｡
2つのメインと名前を付けて､ ユニットテストを実行します｡
ドットメイン｡
これが簡単なセットアップです｡
では､ 今これを実行すると､ Python 3とします｡
テストパイです｡
1つのテストを実行したことがわかります｡
わかりました｡
というわけで､ これが今回の設定です｡
次に､ これを実際に取り出して､ 関数に抽出し､ テストファイルで使用できるようにしたいと思います｡
だから､ こっちのトップで言うんです｡
私たちの推測を定義します｡
ゲームというか､ ランといいましょうか｡
推測する｡
それはインプットを受けることになります｡
あるいは推測としましょう､ そしてこのコードを実行するのです｡
では､ そうしましょう｡
取るつもりです｡
このコードの一部｡
こんな感じ｡
そして､ それをここに貼り付けるだけです｡
さて､ 間違った推測には､ 答えの変数も必要になってきます｡
そこで､ 第2パラメータで回答します｡
こんな感じ｡
そうすれば､ あとはこの中に入っているだけでいいのです｡
この関数を推測と答えで実行します｡
ただ､ それだけなんです｡
では､ ここに保存して､ このテストを実行してみましょう｡ あるいは､ 実際のファイルを実行して､ まだ動作していることを確認してみましょう｡
あ､ あと､ そこでちょっとインデントが入るんです｡
だから､ インデントが正しいかどうか確認する必要があるんだ｡
なぜなら､ Pythonではそれが何かを意味することを忘れてはならないからです｡
わかりました｡
今､ 私たちは問題を抱えています｡
breakというキーワードを使いながら､ まあ今ループの外にいるわけですから､ break outside of loopがありますね｡
だから､ 一つ言えることは､ ここで返せということです｡
では､ もう一度実行してみましょう｡
そして､ 名前を当て続けてください｡
あるいは数字｡
そして､ そこにあるのは
これはまだ使える｡
この井戸は走って帰ってくるので､ ここでリターンを使うことができるんです｡
でも､ 今はまだゲームの中です｡
だから､ 戻るだけでいいのかもしれない｡
本当です｡
そして､ もしと言う｡
ラン推しです｡
本当なんです｡
ここから脱却するんだ｡
もう一度｡
ゲームを始めましょう｡
これだけクリアして､ もう一度ゲームを走らせてみる｡
1､ 2､ 3､ 4
そして､ そこにあるのは
番号を入力しました｡
私は天才だ｡
今､ ゲームを終えたところです｡
見やすいように､ もう少し小さくしてみましょう｡
だから､ 私たちは走っているのです｡
コードを少し修正したと思ってください｡
しかし､ 重要なのは､ Runのようなものをテストできるように､ 機能の単位を抽出したことです｡
推測する｡
だから､ 私は私たちのコードを修正したように見えますが､ コードはまだ動作しています｡
では､ さっそくrun guess関数をテストしてみましょう｡
ここに行こう｡
そして､ スクリプトのインポートを開始します｡
そして､ この中でいくつかのことを行います｡
まず､ 答えが､ 例えば､ 5と同じになるようにしたい｡
そして､ 推測は5と同じになる｡
だから､ 推測と答えが一致したら､ まあ､ 間違った客がif文を通過して､ あなたは天才ですとプリントアウトするか､
ノンケースがtrueを返すようにしたいのです｡
そこで､ self dot assertとします｡
イコールです｡
そのスクリプトか実際に初めて実行してみましょう｡
そこで､ resultをscriptのdotと等しくしてみましょう｡
何だったんだろう？
走れ､ 当てろ｡
走る｡
推測する｡
そして､ その答えを教えてあげてください｡
と推測する｡
そして､ その結果を期待しています｡
戻る｡
本当です｡
だから､ アサートトゥルーと言えばいいんです｡
その結果は真である｡
今､ これを実行すると｡
あ､ 実際にゲームを立ち上げてみます｡
では､ どうすればこれを解決できるのか｡
さて､ これを閉じて実際にif名Mainを追加してみましょう｡
この中に
だから､ この下｡
このように､ メインファイルが実行される場合のみ､ これを実行するようにします｡
ここでテストに戻り､ もう一度これを実行すると｡
わかりました｡
現在は動作していますが､ アサーションエラーが発生します test game object has no attribute assert true because.
さて私｡
スペルを間違えて
もう一度やってみよう｡
わかりました｡
1回テストが走ったようで､ すべて良好です｡
また､ プリントアウトした様子も確認できます｡
あなたは天才です｡
とても､ 素敵です｡
ちなみに､ このようなテストの仕方を紹介しているのは､ 実際のシナリオがこのようなものだからです｡
壊し続け､ 間違え続け､ そしてそれを修正しようとし､ コードを修正するのです｡
そして､ このテストを実行するだけで､ 私たちのコードがどんどん良くなっていくのがわかると思います｡
なるほど｡
他に何ができるのか？
ここで言っておきましょう｡
これをコピーするのだと｡
そして､ 物事を短くするために､ ここに直接パラメータを入力します｡
ただ､ それだけなんです｡
入力と言いましょうか､ 不正解と言いましょうか｡
あるいは
当てずっぽう｡
だから､ 答えが5で､ 0を推測するとしよう｡
だから､ これがfalseになることを断言したいのです｡
だから､ これを実行すると
合格を試すために｡
すごいですね｡
他にここでテストできることは？
わかりました｡
さて､ 推測が0と10の間でもなく､ 1と10の間でもない場合､ それをテストしたいと思います｡
その場合､ プリントを用意しておきたい｡
おい､ ボゾ｡
1から10まで言いました｡
だからもう一度､ テストができるんです｡
私の推測が外れていればの話ですが｡
番号です｡
例えば､ 答えが5なのに､ 11を出すとします｡
断言したい｡
まあ､ 今はプリントしているだけで､ 何もしていないんですけどね｡
だから､ ここで一貫性を持たせるために､ falseを返すべきかもしれません｡
また､ そうして私が走れば｡
これでよしとする｡
3つのテストが合格している｡
それは素晴らしいことです｡
それに､ もっともっとたくさんのテストが書けるはずです｡
もうひとつ､ テストをしてみようか｡
入力が文字列の場合はどうでしょうか？
これを実行すると
ああ｡
そして､ その間違いを確認すること｡
ここに入力します｡
名前が違うことを確認する｡
そして､ 4つのテストを実行しています｡
なぜなら､ これは通過せず､ falseを返すからです｡
今､ ここでできることはまだまだたくさんあります｡
でも､ 今ならテストの威力を実感できるはずです｡
私とテストが違っても大丈夫です､ 皆さん｡
テストケースが違う｡
テストのポイントは､ とにかくシンプルにすること｡
私たちのコードを見て､ どのように改善できるか､ どのようにコードを壊すことができるか､ どのようにコードをより小さな単位に分割して単純化できるか､
より小さな単位でテストし､ おそらく私たちが考えたかったいくつかのエラーを修正することができるかを確認するのです｡
他にもいろいろなことができますが､ ここでは､ 小さなピースを一度に扱うという発想に気づかれたことでしょう｡
それをテストして､ さらにコードのこの部分､ あるいはtryとacceptの部分を見てみましょう｡
そして､ ここからが本題です｡
会社勤めをしていると､ できるテストは無限にあると主張します｡
ここに数百行を用意して､ コードをビット単位でテストすることができます｡
でも､ 何度もテストしているからと言って､ 本当に良いテストができるわけではありません｡
先ほども言ったように､ テストは無限に書けるんです｡
アイデアは､ ほとんどのケースをカバーする良質のテストに書くことです｡
しかし､ 最終的には､ コードを書くこととテストを書くことの間でトレードオフをしなければならないような､ 収穫逓減の状況に陥るでしょう｡
また､ 仕事の内容によっては､ テストに力を入れ､ コードに力を入れないといけない場合もあります｡
また､ テストを書いている暇がないほど速く動かなければならないこともあるでしょう｡
また､ ビジネスニーズによっては､ それもありかもしれませんね｡
しかし､ このセクションで､ ソフトウェア開発におけるテストに続く原則のいくつかを理解していただけたと思います｡
つまり､ 私たちのコードには必ずバグが発生するのです｡
そして､ そのために照明を使うことができるのです｡
しかし､ 私たちのコードが正しく動作していることを確認する最良の方法の1つは､ テストです｡
また､ 通常､ テストが多いほど､ コードの安定性が高まることを意味します｡
次回作でお会いしましょう｡
バイバイ｡