もっと楽をしたい！安心したい！と思って。ビルドとかテストとかデプロイをいい感じに自動化したいなー。と思って。
CI/CD周りのデプロイメントパイプラインを勉強したいなと思いました。
CI/CDの基礎的な所を勉強しよっと。んで、コンテナCIサービスがどんなんなのか見てみて。んで、僕にとってどういうのがいいのか考えてみよう。
— パパりんず (@bufferings) June 18, 2015で、この本をパラパラと。読み始めました。
そうすると、最初の方に「Chapter 4. Implementing a Testing Strategy」ってところがあって。
あぁ、確かにCI/CDしたいなら、テストについて考えたいな。って思って。
この本の「Part III The Agile Testing Quadrants」を見てみました。books.rakuten.co.jp
ついでに、そういえばJanetは続編だしてたなって思って、こっちもパラパラと。
で、「Chapter 15. Pyramids of Automation」の部分が目に止まったのでした。books.rakuten.co.jp
ということで、Agile Testing Quadrants と Pyramids of Automation について勉強がてらメモを残そうと思う。
まずは、Agile Testing Quadrantsから。
Agile Testing Quadrants
Q1-Q4って番号振ってるけど、テストの順番を示してるワケじゃないヨ。
Tests that Support the Team
チームをサポートするテスト。左の2つね。
Q1 Technology-facing tests (that Support the Team)
コードの内部クオリティのためのテストで、programmer testsとか、developer-facing testsとか、technology-facing testsと呼ばれるもの。TDD(Development/Design)でテストを書きながら開発・設計していくときのテスト。
TDDのテストは僕の中では、より良いデザインへのガイドロープで、通り過ぎた後は思ったとおりに動いてることに自信をもって前進することができる。という感じ。でも、最近だと、僕はテストを先に書くことはあんまりしなくて、不安がある場合くらいかな。なので、コードを書いてある程度ごにょごにょ整理してからテスト書くことが多い。
次のQ2のテストが通るようになったら、そこでカバーされている部分に関しては、このQ1のテストは消してもいいと思っている。Q1のテストで残すのは、Q2でカバーできない部分かな。数カ月後の自分に対して、Q2のテストではカバーしきれない細かいメソッドの挙動を伝えておきたい時とか。
じゃあ最初からQ2のテストだけ書けばいいじゃん。って思うかもだけど。一歩一歩思ったとおりに動いてることを確認しながら進む方が良いよね。家を建てた後に、柱が腐ってることに気づいたら悲しみに溢れてしまうし。それと、ユニットテストって最初にコードを使う人なので。テストを書くと「あれ？この場合はどうなればいいんだっけ？」って気付かされることが多いので、そういうのも大切。
Q2 Business-facing tests (that Support the Team)
Q2のテストも開発チームをサポートしてくれるんだけど、Q1よりももっとハイレベルで、business-facing testsとか、customer-facing testsとか、customer testsって呼ばれる部分。外部クオリティとか、カスタマーの欲しい機能を定義してくれるテスト。機能レベルのテストで、ビジネスエキスパートが簡単に理解できるようにビジネスドメインの言葉で書かれている。Business-facing testsもできるだけ自動化したらよいけど、UIのデザインとかは自動化はされない。
ここにはAcceptance testsは入らない。Q3とQ4のもっと広い範囲の、ユーザビリティとかパフォーマンスも含むから。
今日はここまで
フムフム。面白い。
