Scrapyのユニットテストを書こうとしたところ、ちょっと特殊かつあまり情報がなかったのでまとめました。いつHTMLが変更されてもおかしくないというクローラーの特性上、正当性チェックよりも実装時のcrawl時間を短縮するための利用をメインにするのが吉かなと思います。 (※主にSpiderのユニットテストに関する記事です) (※Pipeline等のテストはunittestなどで普通に書けるため範囲外です) TL;DR; Spiders Contractsを使います 公式のドキュメント docstringに書く scrapy check spidername で実行できる 自分でサブクラスを作り拡張できる ドキュメントにあるサンプルコード def parse(self, response): """ This function parses a sample response. Some co
2025-09-07 プログラミング初心者必見!おすすめのテキストエディタ8選を紹介 プログラミングをするうえで欠かすことができないツールの一つに、テキストエディタがあります。システム開発の現場では、専用のソフトやツールがあったりもしますが、まずはテキストエディタでコードを書く技術者が多いです。 そして、どのエンジニアも、大体お気に入りのテキストエディタを持っています。 今回は、そんなエンジニアに人気の、テキストディタをいくつか紹介していこうと思います。 テキストエディタとは テキ […] 2025-09-07 【エンジニアが語る】現場でのトラブル体験談 プログラマーになって10年ほどになりますが、これまでにいくつかの現場を経験しました。 社内で請負で仕事をすることも多いですが、現場でも社内でも、仕事をする上で経験することに変わりはありません。 今回は、そんな現場での体験談の中から、現場で
前々回:API BlueprintでWeb APIのドキュメントを生成する - Qiita 前回:API Blueprintとapi-mockでモックサーバを作成する - Qiita 概要 さて、今回はAPI Blueprintを使って作成したWeb APIがドキュメント通りに動作するかを、dreddを使ってテストします。 dreddとは dreddはAPI BlueprintをベースにしたWeb APIのテストフレームワークです。"Language-agnostic"と謳っているだけあってテストのフックにはnode.js以外にもgoやPython、Rubyなど多様な言語が利用でき、またCircleCIやJenkinsCIなどのCIのサポートもあります。 このように、API Blueprintのエコシステムに乗っかることによって、API Blueprint形式で書いた仕様からaglioを使
Djangoのテストについて考えていたところ、以下の記事に出会いました。 Djangoのテストの書き方について勉強したのでまとめる - c-bata web Django Best Practice への道 #2 後者の記事にもある通り、pytestではテストの失敗内容を細かく出せそうでした。 そのため、Django向けのpytestライブラリpytest-djangoを使ってテストコードを書いてみました。 目次 環境 試したけど分からなかったこと 試してないこと テスト対象のアプリ セットアップとアプリ作成 pytest.iniの作成 Modelのテスト URL解決のテスト Viewのテスト Clientを使う場合 RequestFactoryを使う場合 Formのテスト 全体の流れのテスト 正常系 リダイレクトの確認 テンプレートに渡すcontextの値の確認 Viewの確認 データベ
複数の Python バージョンでテストを実行するツールに tox があります。 tox と pytest で Python 2/3 両対応のテストを実行する - forest book tox ツールそのものがとても便利なのですが、この tox テストを並列実行してくれるツールがリリースされました。 detox: Python Package Index 既に tox を使っている環境であれば、detox をインストールするだけで良いです。 $ pip install detox 使い方は tox と全く同じで特別な設定は不要です。tox コマンドを実行する代わりに detox コマンドを実行します。試しに実行してみましょう。 (test)$ detox py26 create: /Users/t2y/work/repo/littlehttpserver/.tox/py26 GLOB s
libuvのPython実装であるpyuvのPython3対応しているときに、Python2.6/2.7/3.0/3.1/3.2で個別にテストする必要がありました。 各バージョンのPythonを入れるのも割と大変だし、各バージョンごとに確認するのも非常に手間です。 lazyな私にはこんなのやってられません。がおー。めんどくせー。 というわけでいろいろテストツールをいろいろ探していたら、79.pyで @aodag さんにtoxを教えていただきました。 早速使ってみたので、軽くメモを残しておきます。 ドキュメント ↓を読めば大体わかるはず。 Welcome to the tox automation project — tox 1.4.2-1 documentation ざっくり説明すると Pythonライブラリを複数バージョンでテストするツールです。 CI(Jenkinsなど)で使うことも想
Automated vs. Manual Testing The good news is, you’ve probably already created a test without realizing it. Remember when you ran your application and used it for the first time? Did you check the features and experiment using them? That’s known as exploratory testing and is a form of manual testing. Exploratory testing is a form of testing that is done without a plan. In an exploratory test, you’
DjangoのWebアプリを開発している際、リファクタ/テスト拡充のために集めた情報をまとめます。本記事は三部作の二つ目となります。 #1 Djangoプロジェクト/アプリケーション/設定ファイル構成 #2 Djangoテスト戦術 #2 補足編 #3 Django Model/View/From/Template戦術 書くこと Django Best Practiceへの道の続きで、Djangoテスト戦術について書きます。Djangoでテストをする際に、どうしたら効率的に書けるか、メンテナンスしやすくなるか、ということに焦点を置いて書きます。 書かないこと テストをするべき、テストはいらない、どこまではするべき、といった類の話は書きません。する、しない、いまはしない、どこまではする、は各チームや開発者がその時置かれているコンテクストに非常に強く依存している為、閾値的なものや考え方を書くのは
追記: この記事の内容はかなり古くなっています。翔泳社さんからDjangoの書籍を出版するので、ぜひ読んでみてください。 実践Django Pythonによる本格Webアプリケーション開発 (Programmer’s SELECTION) 作者:芝田 将翔泳社Amazon はじめに この記事はPython Advent Calendar 2014の12日目の記事です. 昨日は「SushiYasukawa」さんによる(Pythonによる簡単なLispインタープリタ実装方法(四則演算編)) - Python, web, Algorithm 技術的なメモでした. 最近Djangoで何か作ったという記事をよく見かけます. 次のQiitaの記事を参考にDjangoの勉強を始められた方が多いようなので、僕も始めてみました. Python Django入門 (1) - Qiita Python Djan
退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミングposted with カエレバAl Sweigart オライリージャパン 2017-06-03 Amazonで検索楽天市場で検索Yahooショッピングで検索 目次 目次 はじめに Can I use python3でライブラリがpython3で利用できるか確認できる pythonのリポジトリの構成 with構文をうまく使う コードのデバッグをするときはテストファイルを作る。 tkinterはバージョン8.0から外見が洗練された ロギングが print より優れている理由 PythonのテストフレームワークにはNoseを使う Python製のCIサーバ Buildbot Pythonの並列処理にはconcurrent.futuresを使う 参考資料 MyEnigma Supporters はじめに P
tl;dr 作ったもの 知見 requests.get() を mock で置き換える S3 への put_object を moto で置き換える invoke コマンド Travis CI を使って, 複数の Python バージョンでテスト出来るようにする 以上 tl;dr inokara.hateblo.jp 前回の記事の続きというか, 前回, 突貫で作った Python スクリプトを自分なりに作り直してみました. スクリプトを作り直すにあたって, テストを書いたり, その上で Python 3 系の複数のバージョンでテストを Travis CI で回すようにしてみたり, モックを使ったり, 色々と経験出来たので覚書として残しておきたいと思います. 尚, あくまでも「自分なりに」なので, 誤り等あればご指摘頂けると幸いです. 作ったもの github.com 使い方とかは READ
対象の読者 普段Pythonをお使いの方。 特に単体テストコードを書く機会がある方。 Python標準のUnitTestフレームワークを使う機会のある方。 概要 単体テストをする際、1つのテストケースの中で、パラメータを変えて複数回対象をAssertすることがあります。 普通に実装すると、1パターン失敗した時点で、残りのパターンがテストされず、テストは終了してしまいます。 Subtestを用いると、途中で失敗するパターンがあっても、テストを最後まで実行し、成否をパターン毎に個別に出力してくれるようになります。 前提条件 この記事の内容はPython 3.5系で検証したものです。 それ以前のバージョンだと想定通り動かないかもしれません。 テスト対象例 あるメソッドやクラスのテストをする場合、大抵の場合、テスト対象が取りうる入力、状態ないし結果を網羅するように、パラメータを変えてテストをするか
連載の第6回では、Ansibleのテストにおける考え方や方法論を解説していきます。 Ansibleにおいてテストは必要かテストは、対象のプログラムが仕様通りに正しく動いていることの確認や、バグを発見するために必要な工程です。適切なテストをすることにより、対象物(システム)の品質を担保できます。では、Ansibleのような構成管理ツールではどうでしょうか。従来の構成管理の手法としてはシェルスクリプトなどを使い、ミドルウェアのインストールおよびサービスの起動を行っていました。シェルスクリプトはプログラムなので、仕様通りに構成管理が行われていることの確認としてテストをすることがあります。それに対してAnsibleでは、プログラムを使用せずにyaml形式のPlaybookという設定ファイルをユーザーが記述します。そして、そのPlaybookに基づいてAnsible内部のPythonで記述されたプロ
背景 pythonには標準モジュールの中にunittestが含まれるのですが、使い方がすぐに分からなかったため、他のプロジェクトでもコピペできるようにテンプレートを備忘録として残しておきます。 *注意事項 python2.7以上からunittestではsetUpClass, tearDownClassというテストクラスの初期化時に実行されるメソッドを用いることができるようになりました。 python2.6以下の場合は、unittest2というモジュールをインポートすることでこれらのメソッドを使うことができます。 コードのテンプレート ポイント unittest.main()では、setUpClass → (setUp → tearDown) *ループ → tearDownClass が実行されます。 test用のメソッドは名前の先頭を test から始めなければなりません。e.g. tes
Pythonのargparseモジュールを利用するとPythonスクリプトに渡された引数のチェックを良い感じにやってくれます。自動的にヘルプコマンドも作ってくれたりするので、コマンドラインツールを作るときにはかなり便利です。 今回はargparseによるコマンドライン引数のパースをunittests + Mockでテストしてみました。Pythonのバージョンは2系です。 完成形はこんな感じ↓ import unittest from mock import patch, Mock class ParserError(Exception): pass class ParserTestCase(unittest.TestCase): @patch('argparse.ArgumentParser.error') def test_parse_error(self, arg_error): ar
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く