インテグレーションテストのためのユーティリティってないか
Pythonでテストを書くときに、外部への副作用が起こるものは大体標準の mock を使って書く気がする。
まぁいいんだけど、副作用がほぼすべてという場合、mockがもりもり増えてしょんぼりする。
で、コーディングの大半は mock をどこで用意して、mock.patch でどの関数を上書きするかの話になってしまう。特に、import の仕方で patch を当てる場所が微妙に違うというのを見たときはビビった。まじかよ
http://docs.python.org/dev/library/unittest.mock
「26.4.3.8. Where to patch」の部分
副作用がほぼ全てみたいなスクリプトのUnit Testがもっくもくなのは、相当前に初めてそういう話を全力でやった時代から正直あんまり進化してない気がする。
出来れば、言語と関係なく、言語の外側のネットワークやOSレベルをあっさり囲ってくれるインテグレーションテスト用のユーティリティがあると嬉しい。使いやすいとチョー嬉しい。
具体的にAPIとしてどういうものになるのかは知らない。自分で強引にやるのなら、vagrant 等で環境を立ちあげて chef などで何かやる可能性を考えると思うけど、正直「重」すぎるように感じる。
もう夢を語るのすらめんどくさいので、結局もっくもっくするのに留まる。だるくなって書いた昨日の「テスト」は、UnitTestを継承したクラス配下で、実際にgithubにアクセスしてデータ取ってきてコンパイルしてコンパイル結果のファイルが出るかを「テスト」するものだった。全くユニットテストではないし、しかもその過程のstderrとstdoutが他のテスト結果と混じって便利でもなんでもないので、2分で消してコマンドラインから起動すること前提の「インテグレーションテスト」スクリプトに変更した。ああ、だるい。
でもまぁ、このダルさを越すと、もりもりコードが安定するのも事実なんだよな。このダルさ、誰か軽減して。
あん、仕様変わったので書いたテストが無意味になった、だと?(´・ω・`)
全く別件だが、既存のシェルスクリプトのユニットテストを書きたいとき、どうすればよいだろう。
まぁいいんだけど、副作用がほぼすべてという場合、mockがもりもり増えてしょんぼりする。
で、コーディングの大半は mock をどこで用意して、mock.patch でどの関数を上書きするかの話になってしまう。特に、import の仕方で patch を当てる場所が微妙に違うというのを見たときはビビった。まじかよ
http://docs.python.org/dev/library/unittest.mock
「26.4.3.8. Where to patch」の部分
副作用がほぼ全てみたいなスクリプトのUnit Testがもっくもくなのは、相当前に初めてそういう話を全力でやった時代から正直あんまり進化してない気がする。
出来れば、言語と関係なく、言語の外側のネットワークやOSレベルをあっさり囲ってくれるインテグレーションテスト用のユーティリティがあると嬉しい。使いやすいとチョー嬉しい。
具体的にAPIとしてどういうものになるのかは知らない。自分で強引にやるのなら、vagrant 等で環境を立ちあげて chef などで何かやる可能性を考えると思うけど、正直「重」すぎるように感じる。
もう夢を語るのすらめんどくさいので、結局もっくもっくするのに留まる。だるくなって書いた昨日の「テスト」は、UnitTestを継承したクラス配下で、実際にgithubにアクセスしてデータ取ってきてコンパイルしてコンパイル結果のファイルが出るかを「テスト」するものだった。全くユニットテストではないし、しかもその過程のstderrとstdoutが他のテスト結果と混じって便利でもなんでもないので、2分で消してコマンドラインから起動すること前提の「インテグレーションテスト」スクリプトに変更した。ああ、だるい。
でもまぁ、このダルさを越すと、もりもりコードが安定するのも事実なんだよな。このダルさ、誰か軽減して。
あん、仕様変わったので書いたテストが無意味になった、だと?(´・ω・`)
全く別件だが、既存のシェルスクリプトのユニットテストを書きたいとき、どうすればよいだろう。