contentテスト自動化について、調べてみたJavaPHPTDDオブジェクト指向テストテスト自動化について、調べてみたはじめに今までテストコードやテスト自動化をしたことがなく、今の会社に入ってテストコードを書き始めて半年ちょっと言語はphp,javascript(node)が中心テストコードを書く前にどういう経緯で自分がテストコードを書く理由やモチベーションが上げるために、テストコードやテストについて、自分が現在書いている実感も含めて少しまとめ。テスト自動化までの歴史1960年代テスト自動化をする手法は早くは1962年に考慮されているソフトウェア危機1960年代の終わり第1回NATOソフトウェア工学会議で主張された話、コンピュータの高性能化によって、ソフトウェア開発が複雑化が加速化していくと叫ばれた。このころから複雑化していくソフトウェア開発に対し、構造化プログラミングや自動テストなどのソフトウェア開発における方法論が議論が活発化し始めている。1976年ソフトウェアの複雑化が増して行く中でソフトウェアの品質を上げるためのテスト手法の検討や確立がされていった。1988年ソフトウェア開発に関しての有名な論文。言う有名な言葉を残した。いうブルックスの法則の言葉も有名。beckが書いた開発手法の本。現代の自動テストの考え方の主要な考え方が載っている。(詳細は後述)Scrumアジャイル開発の手法の一つ。最近一番よく聞くイメージがある。短い期間でスプリントを組み、スクラムマスター、プロダクトオーナー、チームが協力しあって、プロダクトを作成する手法。スクラムマスターはスクラムの導入の手助けを、プロダクトオーナーはプロダクトにビジネスの要件と責任、チームはプロダクトオーナーからのビジネス要求に応えるという形で互いが協力しあって開発を進めていく。XPと同時期に提唱された開発手法でテスト自動化についての細かい記述はないが、短い期間で開発するための手法として、基本的にテスト自動化が導入されていることが多い。2000年代リーンスタートアップ厳密にはソフトウェア開発手法ではなく、起業の方法論だが、スタートアップ企業でよく使われている開発手法。アジャイルの開発手法の一つ。Product)を作成し、仮説、検証を繰り返し、製品をよくしていく手法。繰り返しのタスクや方法論がXPやアジャイル手法に共通する部分が多くある。(Operations)を組み合わせたかばん語で、開発担当者と運用担当者が連携して協力する開発手法。運用、インフラと開発がシームレスに連携する開発手法。インフラの自動化などと一緒にテストの自動化の導入が提唱されている。ソフトウェアテストの種類テストの種類。会社によって色々な呼び方がある。testはこちらに類する外部APIなどの外部接続するものテストを段階的に行う場合もある基本的にブラックボックステスト、場合によってホワイトボックステスト的なイメージ総合テスト外部APIやブラウザなど全ての条件を結合するテスト本番と同等の環境を用意してテストを行う。ビジネス要件を担保するテストではないメソッド毎に作成する。粒度は細かめ他のmoduleに依存する部分はstub,mock化してテストするメリットテストコードを書くことで各moduleの機能範囲などを開発者がより深く理解することできる粒度が細かく、バグが発生した箇所を細かく分析することができるメソッドの機能を表現するテストコードができて、開発者はテストコードを読んでそのメソッドの意図を後から読解することができるデメリット網羅性を要求されるため、ロジック内容にによってテストコードを書くコストが大きくなる密結合なコードだと、テストコードが書きづらく、疎結合なテストが書きやすいコードを要求されやすい機能テストファンクショナルテスト各module(外部APIやDB部分)が連結する部分も合わせてテストを行う。要件への理解まで必要なので理解していないといけない範囲が大きくなるUIテストseleniumやappinumなどの実際のブラウザやアプリを動かすソフトウェアを使って行うテスト、一番粒度が大きい。UIテストの順で重要だと言われています。etc・・・いろんな考慮をしながらプログラマーはプログラムを書かなきゃいけない一回でちゃんとしたコードを書くのは非常に難しい。仕様変更がある可能性もある。テストコードがないプログラムはどこが壊れるかわからない。程度かかると思います。(個人的肌感)テストコードがないコードにテストコードを導入する場合はコード本体がテストコードを書かれることが意識されていないため、テストコード導入のコストが多くかかることが多い。beckによってXPのベストプラクティスの中の一つとして提唱されたXPとテストコードXPでは短いサイクルでの開発を前提としていて、常に要件とコードが変化していく、プログラマーはその全てを理解し切ること困難な中でリファクタリングを行っていく。発展の開発手法にBDDやFDDがある(やったことはないのでよく知らない)テストファーストTDDの基本的な方法論の一つ、実装する前にテストを書き、実装内容のインターフェイスを決定してから実装することで実装の動きを担保し、実装と同時にテストコードもある状態にする手法。(継続的インテグレーション)テストコードを導入するプロジェクトでは、導入したテストコードを自動的に実行する環境を導入することを提唱されている。CIなどのCI機能に特化したサービスなども展開されている。最近ちょっと意識してやっていること、考えていること実装のMR・PRを作成する際にその実装のテストコード(少なくとも正常系)を一緒につけるレビュー側もテストコードの内容で実装内容を確認できるし、自分もそのコードの確認のテストを出来て良い。要件がふわっとしている場合まずは要件担保するファンクショナルテストをゆるい検証内容で書いて、要件のfix後に細かい粒度のテストを書くようにする要件がカチッとしている場合ユニットテストから書く(書きたい)テストの範囲と名前、意味について単体テストと機能テストを指す定義の範囲ちゃんと区切りたい。純粋な意味の単体テストならば、他のmethodに依存する部分は全部mockやstubにしてテストするべきなのか。思うのですが、確認したい範囲によって、ちょっと結合してやりたいって場合があったりする場合は結合テストという名前になるのか?そうだとしたら結合テストって言葉の指す範囲はあまりに広いなぁと思ったり、もうちょいテストの範囲や意味を整理できる言葉が欲しい。最後にテストコードは銀の弾丸ではない。テストコードには色々なメリットはありますが、決してどんな場面にも有効な銀の弾丸ではありません。言う勇気ある選択肢を持つことは良い結果をもたらすことがあると思います。勉強不足で勘違いや不足があると思うので色々編集リクエストをいただけると嬉しいです。upLoginユーザーは見つかりませんでした。