webtestgithub.comgo-webtestというパッケージを作ってました。testingそしてコンセプトは以下の通りです。simple場合によっては便利な方がシンプルなことより嬉しいときがあったりしますね。APIのテストをしようとしたときにどういう体験をしたいかということを気にして作っていました。testingがしたい例えば以下の様なAPIがあるとします(handlerの実装が知りたい人はこちら)。30}まず成功例だけを書いてみることにします。以下の様なテストコードになります。0.008s例えばちょっと引数を変えて実行してみます。}以下のように失敗します。0.004ssnapshotを更新しましょう。ときには全てのsnapshotを更新します)。0.006s今度は上手くいってます。testingと言います。似たようなものはpythonではcrvpyやsnapshottestなどが有ります。testingの雰囲気を掴みたい人にはjestのドキュメントなども良いかもしれません。怠惰なassertionが殺意を招くもうちょっとだけ続きます。今度はこちらの話です。apiのテスト時に発生するフラストレーションを緩和するような機能これは単刀直入に言えばテストが失敗したときのエラーメッセージが豊かになっていて欲しいという話です。APIの変更の結果テストが壊れるとします。その壊れたテストを直すときにステータスコードだけ分かっても嬉しくなかったりします。OK"分かることがステータスコードだけというのはけっこうツライですね。幾つかある不正な入力の可能性から誤りであったrequestのパラメーターなどを特定しなければいけない。途中参加したプロジェクトなどでテストの実行に時間がかかっている上でそのような状況だとストレスがやばい(やばい)。フラストレーションが溜まります。発生したエラーなども出てきて欲しいですよね。bodyに含まれるはずです(ですよね?)。それをテストコードで潰してしまうのは。良くないことなんです。bodyも見えていて欲しい。0.006s万策尽きてのtrace意図しないresponseが返ってきてしまうテストの原因は何なんでしょうね?あるいは変にラップされた便利ライブラリ(のようにみえる)コードに依存した処理のテストコードなどではどのようなrequestが投げられているのか把握しづらかったりします。ストレスに精神がやられて頭を働かせたくない状況だとかあったりしますね。万策尽きた状態のときだとか。付けるとrequest/responseをtraceしてくれます。0.003sあー、なるほど。stringに数値だけではなく文字列が混ざっていますね。ちなみにテストが成功しているときにも使えます(testing.TBを使わずstderrに出力している辺りはちょっと直したいかもなーと思ったりもしています)。(matched)"などのdebug表示と組み合わさっていると404のときの原因を調べるのにも意外と便利な気がしています。他にももう少し色々あるんですが今回はこのへんでおしまい。componentという機能を追加した月別アーカイブはてなブログをはじめよう!podhmoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。