テストの実行ターミナルから、次のコマンドでテストが実行できます。'default'...ここでは以下のようなことを行なっています。返していることを発見テストは私たちにテストの失敗を教えてくれるだけでなく、失敗が起こったコードの行数まで教えてくれる。私たちはすでに問題の原因を知っています。返さなければならない、ということ。'default'...バグを発見した後、私たちはそのバグをあぶり出してくれるようなテストを書いて、コード内のバグを直したので、テストは無事にパスしました。このアプリケーションでは将来、たくさんの他のバグが生じるかもしれませんが、このバグがうっかり入ってしまうことは二度とありません。テストを実行するだけで、すぐに警告を受けられるからです。アプリケーションのこの小さな部分が、安全に、そして永遠にピン留めされたと考えて差し支えありません。メソッドをさらにピン留めしておけます。実際、一つのバグを直したことでほかのバグを作り出すなんてしたくありませんので。このメソッドの振る舞いをより包括的にテストするために、同じクラスにさらに2つのテストを追加してみます。過去、現在、そして未来の質問に対して意味のある値を返すことを確認する3つのテストが揃う。簡単なアプリケーションであっても、将来このアプリケーションが他のどんなコードと関係するようになっても、複雑さは増していく。メソッドに対してテストを書いたおかげで、今ではそのメソッドが期待したとおりに動作することを、ある程度保証でききるようになったことになる。ビューをテストするこの投票アプリケーションは、まだ質問をちゃんと見分けることができない。フィールドが未来の日付になっている質問を含め、どんな質問でも公開してしまいます。この点を改善するべきでしょう。その日付になった時に公開され、それまでは表示されないことを意味する。ビューに対するテスト上でバグを修正した時には、初めにテストを書いてからコードを修正しました。実は、テスト駆動開発の簡単な例だったわけです。テストとコードを書く順番はどちらでも構いません。ブラウザを通して経験する動作をチェックしましょう。初めに何かを修正する前に、使用できるツールについて見ておきましょう。Clientを用意している。shellでも使うことができる。shellを使って見る。必要がない2つの準備が必要になる。上でテスト環境をセットアップすること。setup_test_environment()setup_test_environment()は、レンダリングのテンプレートをインストール。含むような、レスポンス上のいくつかの追加的な属性を試験が可能になる。よってはアウトプットが多少異なるかもしれまない。正しくない場合は、予期しない結果になる。設定変更がまだの場合は、次に進む前に設定を確認してください。クラス自体がクライアントを持っているため、インポートは不要)。Client()さて、これでクライアントに仕事を頼む準備ができました。投票が表示される状態になっている。ベースにしたクラスベースビューを導入しました。比較して確認できるようにする必要があります。メソッドを修正します。含んだクエリセットを返します。新しいビューをテストするそれでは、これで期待通りの満足のいく動作をしてくれるかどうか確かめて見る。実行して、ブラウザでサイトを読み込む。作成し、すでに公開されている質問だけがリストに表示されるかどうかを確認。shellのセッションに基づいてテストを作ります。簡単に作れるようにするショートカット関数と、新しいテストクラスを作成。これらのコードを詳しく見ていきましょう。create_question。作成する繰り返しを取り除いてくれています。空になっているか確認。メソッドを提供していることに注意。リストに現れるかどうかを検証。未来の日付の質問を作成。データベースは各テストメソッドごとにリセットされるので、この時にはデータベースには最初の質問は残っていない。以下のテストメソッドも同様です。実際のところ、私たちはテストを用いて、管理者の入力とサイトでのユーザの体験についてのストーリを語り、システムの各状態とそこでの新しい変化のそれぞれに対して、期待通りの結果が公開されているかどうかをチェックしている。知っていたり推測したりしたユーザは、まだページに到達できてしまいます。追加する必要があります。表示されないことを確認するテスト。メソッドを追加して、新しいテストクラスも作らなければならないようです。これは、今作ったばかりのものとそっくりになるでしょう。実際、テストは重複だらけになるはずです。テストを追加することによって、同じように他の方法でアプリを改善できるでしょう。公開可能になっています。排除するようビューでチェックできます。ことをテストすることになるでしょう。Questionsを見ることができるようにした方がいいかもしれません。繰り返しになりますが、この問題を解決するためにソフトウェアにどんなコードが追加されべきであったとしても、そのコードにはテストが伴うべきです。テストを先に書いてからそのテストを通るコードを書くのか、あるいはコードの中で先にロジックを試してからテストを書いてそれを検証するのか、いずれにしてもです。ある時点で、書いたテストが限界に達しているように見え、テストが膨らみすぎてコードが苦しくなってしまうのではないかという疑問が浮かんでくるでしょう。なって場合にはどうすれば良いのでしょうか?テストにおいて、多いことはいいことだ私たちのテストは、手がつけられないほど成長してしまっているように見えるかもしれません。この割合で行けば、テストコードがアプリケーションのコードよりもすぐに大きくなってしまうでしょう。繰り返しは、残りの私たちのコードのエレガントな簡潔さに比べて、美しくありません。テストコードを大きくしましょう。あなたはテストを一回書いてそのことを忘れます。プログラムを開発し終えるまで便利な関数を使いそれを続けましょう。時には、テストにアップデートが必要になることがあります。公開するよう、ビューを修正したときのことを思い出してください。この後、既存のテストの多くは失敗します。わたしたちに教えてくれているのです。テストはこの意味でも、テスト自身をチェックするのに役に立っています。最悪の場合、開発を続けていくにつれて、あるテストが今では冗長なものになっていることに気づいてしまうかもしれません。これも問題ではありません。テストを意味のあるものとなるように整えている限り、手に負えないものになることはありません。経験上、次のルールを守るようにすれば問題ありません。分割するテストしたい条件の集まりのそれぞれに対して、異なるテストメソッドを作るテストメソッドの名前は、その機能を説明するようなものにするさらなるテストこのチュートリアルでは、テストの基本の一部を紹介しました。この他にもあなたにできることはまだまだたくさんありますし、いろいろと賢いことを実現するに使えるとても便利なツールが数多く用意されています。フレームワークを使うこともできます。振る舞いも確認できます。テストがブラウザを起動してサイトとインタラクションしているのを見るのはとても面白いですよ。LiveServerTestCaseが用意されています。ために、コミットの度に自動的にテストを実行したいくなるかもしれませんね。継続的インテグレーションを行れば、品質管理それ自体が、少なくとも部分的には自動化できます。アプリケーションのテストされていない部分を発見するには、コードカバレッジをチェックするのが良いやり方です。これはまた、脆弱なコードや使用されていないデッドコードの発見にも役に立ちます。テストできないコード片がある場合、ふつうは、そのコードはリファクタリングするか削除する必要があることを意味します。カバレッジはデッドコードの識別に役に立つでしょう。コピペだらけになってきたな・・・。(1)ブログランキング?にほんブログ村にほんブログ村にほんブログ村にほんブログ村ふぉろみー@aqaua1211さんをフォローリンクはてなブログブログをはじめる週刊はてなブログはてなブログPro月別アーカイブ参加グループ知識はてなブログをはじめよう!apistさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。