雑ノート(仮)

適当なメモ。

テストコードについて勘違いしていたこと

テストのリテラシーがないままテストコードを用意していた

自動テスト、と言ってもテスト設計自体は自動ではなく、人間が行わないといけない。 その時もちろんテストの知識が問われる。

テストコードは実装後に用意していた

本格的にテストコードを書いたのはsalseforceの環境が始めてでした。 salesforceではステートメントカバレッジがテスト時に75%を超えないとリリースできないので、 コーディング後に如何にカバレッジを上げるテストを書くか。そのついでにassert()を行うか、という視点でコードを書いたので salesforce以外のテストでも同じような視点でテストコードを書いていた。

フルシナリオのテストを実施するコードを書いていた

テストコードはスピードが命。 画面テストをしなくても良いような凄いリッチなテストを作ることはxUnitの目的ではない。

TDDと自動テストを混同していた

自動テスト

selenium等のツールによるよりユーザー操作に近い自動テストなどが含まれる。 かなり広義のいみになるのでTDDなども含まれる。

TDD

テストコードを作成してからコーディングを始めること。 高速に実施されるクラス、メソッド単位でのテスト 結合している部分で遅くなりがちな箇所(I/OやDB接続等)はモックで置き換えるなどの工夫をして高速に実行出来るようにする。 とにかく早く実行が終わり、作成中/修正中のPGの正しくない箇所に来づけるようにする。

テストコードを書けば他のテストを実施しないで良いと思っていた。

「自動テスト」という言葉に惑わされて勘違いしていた。 「人工知能」並に勘違いを招く言葉だと思う。

コードの正当性検査スクリプト、くらいのノリで良いんじゃないか。

テストコードは開発・保守の効率向上のためのテスト。 画面を操作してキャプチャを撮ったりするのは品質のためのテスト。 テストコードを書くことで、些細なコーディングミスや不整合に早い段階で気づくことが出来るが、 ユーザー目線の操作のテストをやらないで良いことにはならない。

dev.classmethod.jp

9.ユニットテストさえすればインテグレーションテストをしなくて良いという勘違い

意味的にはこれが近い。

ちなみに納品のためのテストやアリバイ工作のためのテストはやりたくない。 上記リンクのJUnitのテストコードを納品する必要があるから云々はまさにそれだと思う。

多少面倒でも意味のあるテストにしたい。