Djangoでテストをするときは、 python manage.py test とすることでいい感じでテストケースを探してくれてテストをしてくれるわけなのです。 とりあえず共通的な処理をするものをプロジェクトの下に lib というディレクトリを作って、この中に共通処理をする関数を入れた common.py というのを作って、そのテストを行う tests.py を以下のような感じで作ってみました。 from django.test import TestCase from lib.common import func class GmapHelperTestCase(TestCase): def setUp(self): pass def test_func(self): self.assertEquals('aaa', 'bbb') そして settings.py の INSTALLED_
2006/09/03 23:46 ※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】 最近追加されたテスティングフレームワークを試したみた。 Djangoは基本的にはPython由来のdoctestやunittestを用いてテストを行う。最近追加されたテスティングフレームワークは、アプリケーションの直下にあるmodels.pyやtests.pyを自動的にAllテストしてくれるというもの+Viewのテストを行う疑似ブラウザともいえるClientというクラス。 Railsと同じく、Djangoもテストの前にテスト用データベース・テーブルを生成し、初期データを流し込み(fixtureは現在実装中)、テストを行い、テスト用データベースを破棄するという流れ。おいおい、そんな流れは業務系とか既存データベース使うアプリにはできんぞ、せめてビューとかシノニムとかに
testing tool nose の Django 対応版 nose-django 。 settings は読み込めたものの TypeError や NameError が山ほど。 なにか使い方が間違っているんだろうなぁ。 $ cd site-packages $ sudo svn checkout http://nose-django.googlecode.com/svn/trunk/ nose-django $ cd nose-django $ sudo python setup.py install $ nosetests --help usage: nosetests [options] [names] nose provides an alternate test discovery and running process for unittest, one that is i
Djangoのテストフレームワークは便利なんだけど、テスト実行時に毎回行われるDBテーブルの生成・削除プロセスやFixtureデータのインポート処理に決行時間が掛かってて、ストレスの種になっていた。 テスト中にコンソールを眺めていて特に遅いと感じられるのがcreate table文の実行。モデルの数だけこれが実行されるので、アプリケーションの規模が大きくなるにつれテスト時間も増加してしまう。 DBアクセスが高速化されればいいんだけど、今回使用しているDBのPostgreSQLにはメモリテーブルみたいな仕組みがないため、どうしてもディスクアクセスが発生してしまう。が、ローカル環境では開発用途にしか使ってないのでRAMディスク上にテーブルスペースを作って、そこにテスト用のDBが生成されるようにすればDBアクセスが高速化されるはず。と思い立って、次のようにこれを実現してみた。 まず導入したのが前
Testing in Django¶ Automated testing is an extremely useful bug-killing tool for the modern web developer. You can use a collection of tests – a test suite – to solve, or avoid, a number of problems: When you’re writing new code, you can use tests to validate your code works as expected. When you’re refactoring or modifying old code, you can use tests to ensure your changes haven’t affected your a
追記 2007/11/24 ここに書いたようなややこしい方法をとらないでも $ python manage.py test とすればアプリケーションディレクトリ(普通models.py の入ったディレクトリ)に置いたtests.pyというテストファイルを実行することができます。 ドキュメントはきちんと読みましょう orz (tokibitoさんありがとうございます) http://michilu.com/django/doc-ja/testing/ 以下の文章はなんらかの理由で上記のコマンド使いたく無い人か、どうやったらテスト前の環境を自力で設定できるのかを知りたい人向けです(そんな人いるのか?) -------------------------------------------------------------- Django アプリケーションに対し unittest を実行したと
最近追加されたテスティングフレームワークを試したみた。 Djangoは基本的にはPython由来のdoctestやunittestを用いてテストを行う。最近追加されたテスティングフレームワークは、アプリケーションの直下にあるmodels.pyやtests.pyを自動的にAllテストしてくれるというもの+Viewのテストを行う疑似ブラウザともいえるClientというクラス。 Railsと同じく、Djangoもテストの前にテスト用データベース・テーブルを生成し、初期データを流し込み(fixtureは現在実装中)、テストを行い、テスト用データベースを破棄するという流れ。おいおい、そんな流れは業務系とか既存データベース使うアプリにはできんぞ、せめてビューとかシノニムとかに気づいてくれよー。 とか思いつつ。(現実的には、デフォルトのTEST_RUNNER設定であるdjango.test.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く