fbpx
  1. HOME
  2. ブログ
  3. IT技術
  4. 【Python】[第5回] Responderを使ってDjangoチュートリアルをやってみた【自動テスト導入編】

【Python】[第5回] Responderを使ってDjangoチュートリアルをやってみた【自動テスト導入編】

Responderを使ってDjangoチュートリアルをやってみた~第5回~

前回の記事の「【第4回】Responderを使ってDjangoチュートリアルをやってみた【公開ビュー作成編】」の続きです。

今回も、Responder(レスポンダー)を使って「Djangoのチュートリアル」をやってみたいと思います。

Django のチュートリアル「はじめての Django アプリ作成」を、Responderで追う形になりますので、多少内容が異なる部分がありますが、成果物はできるだけ同じモノになるよう作る予定です。

【はじめての Django アプリ作成】
https://docs.djangoproject.com/ja/2.2/intro/

第1回はこちら

自動テストとは?

この記事は、はじめての Django アプリ作成、その5 」に沿って書かれており、「テスト」について言及されています。

テストとは、自分で書いたコードが正しく動作するかを確認するために行います。

小さなもの(あるひとつの関数メソッド)に行われる場合もあれば、ソフトウェア全体に対して、ユーザが行うであろう一連の動作に対して期待通りの出力が得られるかを確認するために行われる場合もあります。

今までやっていた作業とは少し毛色が違いますが、飛ばさずに実際に手を動かしてみましょう!

なぜテストを作成する必要があるのか?

この記事で作成したPollsアプリケーションは、一見、投票アプリとして正しく動作しているように見えます。

では、なぜテストを作成しなければならないのでしょうか?

テストは時間節約につながる

「実際にアプリを動かしながら、正しく動いているか確認する」というのもテストとしては十分です。

しかし、アプリケーションが複雑になればなるほど、各機能の相互作用が複雑になっていきます。

ある部分を変更したら、他の部分の結果が変わるかもしれません。

そのたびに、実際にアプリを立ち上げて実際に手を動かしてテストするのは時間の無駄でしょう。

色々なテストをあらかじめ作成しておけば、変更のたびに「たったひとつの命令」を実行するだけでバグを炙り出せるのです。

テストはチーム開発に役立つ

大きなアプリケーションになると、単独開発とはいかないことでしょう。

複数人で開発することは、他人の書いたコードのメンテナンスに多くの時間を使ったりと、困難なことも多いです。

しかし、テストコードがあると、それを実行するだけでどこで問題が発生しているのかを内面から照らしてくれます

それゆえに、プログラマとして良いテストコードを書けるようになる必要があります。

はじめてのテスト作成

ということで、この記事でテストコードを書く練習をしていきましょう!

運良く、このPollsアプリケーションには、すぐに修正可能な小さなバグがありました。

Questionクラスの was_published_recently()は、「最近の質問」に対して True を返す(適切な動作)メソッドです。

しかし、未来の日付に対しても True を返してしまいます。(不適切な動作)

未来の日付は「最近ではない」ので、この結果は明らかに間違っています。

それでは、このバグに対してテストを作成してみましょう。

テストを作成

新しく、 test_sample.py を作成し、以下の内容を書いて保存してください。

Responderでは、テストはサポートしていないので、pytestと呼ばれるモジュールを使用します。(公式でも推奨)

したがって、 import pytest を記述します。

その次に、実際にアプリを実行するファイルをインポート( import run as myApp)します。

ここでは、分かりやすくするため、名前を myApp としてインポートしています。

そして、ResponderのAPIをインスタンス化しておきます。

その下に実際にテストする内容を書きます。

  1. クラス名は class TestXXX
  2. メソッド名は def test_XXX(api)

基本的に、クラス名は class TestXXX 、メソッド名は def test_XXX(api) としましょう。

ある関数に対するものなら、XXXは関数名の方が望ましいです。

実行

それでは、実行してみます。

すると、

このようにテスト結果が返ってきます。

返ってきた内容は以下のようになります。

  1. ディレクトリ内のテストファイルを探す
  2. テストファイルを実行し、成功したか  test_sample.py F
  3. 失敗したテストと、原因となる処理

バグを修正する

問題の場所が特定でき、バグへの対処法も分かっています。

未来の日付のときは、 False を返すように修正しましょう。

実行

そうしたら、もう一度テストを実行してみます。

テストにpassしました!

(Warning はとりあえず今はスルー)

小さなテストコードですが、今後アプリケーションが複雑になったとしても、期待通りの動作をするかどうかを簡単にテストできるようになりました。

より包括的なテスト

ついでに、他のテストケースも書いてみます。

今からやるのは、いわゆる境界値テストというものです。

入力された数値やデータが何かしらの閾(しきい)値によって、出力が異なるような処理を書いた場合、その閾値付近でテストを行います。

例えば、以下のようなテストが良いでしょう。

これで、Questionテーブルの公開日に対しては、過去、現在、未来すべてのテストが完成しました。

その他バグ取り

今、作っている投票アプリケーションは、まだ質問を適切に見分けることができません

pub_dateフィールドが、未来の日付になっている質問も公開してしまいます。

本来、公開日が未来であれば、その日付になったときに公開されるようになるべきです。

urls.py

したがって、urls.pyのIndexクラスにおける get_queryset() は以下のように修正しておきましょう。

詳細ページの修正

今の所、とてもうまくアプリケーションは動いています。

しかし、まだ考慮すべき点が残っています

先ほど未来の質問は表示しないようにコードを修正しましたが、実はURLを知っていれば未来の質問にたどり着けてしまいます

もし、未来の質問詳細ページにアクセスしようとする人がいたら、質問一覧のトップページにリダイレクトさせるようにしましょう。

さいごに~第5回~

今回は、テストバグ取りについてお話ししました。

Responderには、Djangoと違って独自のテスト機能はありません

最初に言ったようにPytestを用いたテストをしているため、Responderにおけるテストは工夫が必要になってきます。

本記事では、簡単なテストケースの紹介しかできませんでした。

ですが、本来、Djangoのチュートリアルではビューのテストも紹介しています。

ResponderとPytestでのビューテストは、かなり複雑になってしまうため今回は飛ばしました。

今後、Responderのアップデートで、テストについて充実していくかもしれませんね。

第6回に続く

第6回はこちらになります。

関連記事

一緒に働いてくれる仲間を募集しております!

ライトコードでは、仲間を募集しております!

当社のモットーは「好きなことを仕事にするエンジニア集団」「エンジニアによるエンジニアのための会社」。エンジニアであるあなたの「やってみたいこと」を全力で応援する会社です。

また、ライトコードは現在、急成長中!だからこそ、あなたにお任せしたいやりがいのあるお仕事は沢山あります。「コアメンバー」として活躍してくれる、あなたからのご応募をお待ちしております!

なお、ご応募の前に、「話しだけ聞いてみたい」「社内の雰囲気を知りたい」という方はこちらをご覧ください。

ライトコードでは一緒に働いていただける方を募集しております!

採用情報はこちら

関連記事