技術ネタやスマホ考察、子育て、英語学習などを綴るブログです。Webサービス/アプリを作っています。ポッドキャストで、テストに関する話題がとても面白く勉強になりましたので備忘録メモ。全部テスト書いてたら時間が足りないし、個人的にはどの部分を重点的にテストすべきか、削っても良いのはどこかに注目して聞きました。英単語を画像イメージで楽に暗記できる辞書サイトを作りました。対するテストは書かない。・モックは一番外側のAPI、インターフェースに対してだけ使う。(※)・モックのためのモックとかは避ける。・リファクタリングのためにテストを書き換えなきゃいけないようなテストは駄目。・テストとコードを同時に変更すると、トラブルに気付きにくくなるので避ける。(※)・テストで何を守るのか、将来それで守れるのかよく考える。・正規表現はテストファースト。試行錯誤をテストに残す。(※)・予想できない外部入力に対する振る舞いをテストファーストで書くのは無理。(※)・十分な自信・安心を得られる最低限のテストを書く。使うテストは少なめに。・テストが通るのを1回確認したらコミットしない!(テスト時間短縮のため)・UIはテストしない方が良い、UIの使い勝手はテストで書きにくい。壊したり直したりを繰り返す。・新しい物を作りたいモチベーションが高い時は、テストファーストでなくても良いのでは。サンプルにテストファーストは出てこない。・動く嬉しさでプログラミングを持続できる。(※)は特に参考にしたい項目。感想と個人的な方針など結構聞いていて納得できる部分が多かったです。先に実装アイデア浮かんだ時とか、ばーっと実装コード書いて後でテスト追加とかしょっちゅうやるんですけど、まあその書き方でも良いかと確認できたのは良かった。アイデアや作りたい物が頭に浮かんだ時に、先にテスト書かなきゃと考えると自分の場合萎えます。モックやスタブは都合の良いように取り繕えるので、できるだけ使わないようにしてる。正規表現は確かにテストファーストで書きやすいです。試行錯誤は頻繁に行いますので、これをテストに残すのは今後取り組んでいこう。使うテストの場合、自分は出力させるべきデータ(サブミットされたフォーム入力データや、DB内からのユーザー名・計算した数字など)の確認を重点的にテストするようにしてます。CSSやレイアウトなどUI・デザインは変更が多いのであまりテストに含めないようにしてる。デザイン・UIはテストに向かないなぁというのは実感としてあります。認証、購入まわりなどを重点的に書くのはすでにやってるので再確認。以上のような感じです。聞いてみてください!WEB制作・開発に関わられる方にはとてもおすすめなポッドキャストです。本の中では一番役に立った本です。共によく使用される技術にも触れてあります。機能全体を網羅されています。英単語を画像イメージで楽に暗記できる辞書サイトを作りました。サービスを作っています。拡張など開発業務の受託案件もお引き受けしています。お仕事のご依頼、ご相談はお問い合わせページからお願いいたします。