はじめに

過去に色々と自動テストを導入する方法とかを書きました。とはいえ、なかなか進めるのが面倒な場合がおおいです。実際、2019年11月現在、Googleで「TDD テストファースト」と日本語検索をすると、ネガティブな記事がトップの方に来てしまうのが現実です。

そこで、今回は視点を変えて、大勢側に迎合して自動テストをぶっ潰す方法を考えてみることにしたいとおもいます。

自動テストをやりたいとかいう反逆者は以下の記事でも読んでください。

20年物のC言語で作られたシステムのテスト工程を改善しようとした話
https://needtec.sakura.ne.jp/wod07672/?p=9159

意識が高くないVisualStudioを使用した単体テストの自動化
https://needtec.sakura.ne.jp/wod07672/?p=9213

一度、痛い目にあわせる戦略

実は所属組織でテストの自動化の文化をつぶすのに一番いいやり方は、自動テストをさせないことではありません。一度テストを自動化させるプロジェクトを行って大炎上させることです。

人間というのは不思議なもので、可能性があるとそれにすがってしまいます。
それにすがらせないためには、一度、最悪の現実を体験させることです。
一度、テスト自動化を試みたプロジェクトを大炎上させれば、二度とやりたいと言い出すやつは出てきませんし、出てきたとしても、拒否する大義名分ができます。

是非、自動テストを叩き潰したい皆さんは、この記事で紹介するテスト自動化の叩き潰し方を学んでいただいて、テストの自動化を失敗に導きましょう。

人員の選定

ソフトウェア開発は人が重要です。
テストの自動化を叩き潰すのに重要な人員の分類方法は以下の通りになります。

分類ごとの解説

自動化したくない-経験なし

なにも考えずに採用活動した場合、この層が一番厚くなると思います。
ここの層にたいして自動化にたいするネガティブな感情を植え付けていくのが肝要です。
おそらく本記事のやり方を参考にプロジェクトを進めていただければ、それは簡単に果たすことが可能でしょう。

自動化したくない-経験あり

その経験は脅威になりうる可能性もあります。
しかしながら、この層の多くは我々の先駆者たる失敗したテストの自動化プロジェクトの生き残りであるため、我々の最大の味方となりうる層です。

会議の場では積極的に過去のできない話から「難しいです」「無理です」「できません」と言った言葉を引き出して、周りのテストの自動化に対するモチベーションを下げていくのに利用しましょう。

この際、「自動化したい―経験あり」の人間は会議に出さないように全力で阻止します。
あいつらがいると「やり方がわるかったんじゃないっすか？こうやってこうすればうまくいきますよ」とか空気の読めないことを言い出しやがります。

自動化したい-経験なし

作業者として配置した場合、そのモチベーションが脅威になることがあります。
しかしながら、テストの自動化は本で読んだり、セミナー受けたりしただけでは、基本的にできません。

この層の中の一番有効な使い方は、経験と考えは浅いが、意識ライジングな人員を選抜して、リーダー層に任命することです。経験がなく意識だけが高い場合、この記事で書いているようなことを無意識でやってくれるので、それだけでテスト自動化撲滅のためのキーマンになりえます。

また、この層と「自動化したい-経験あり」が接触すると化学反応を起こして計画の障害になりうるので、なんとしても接触を防ぎましょう。

自動化したい-経験あり

なんとしても排除しましょう。
やむえずプロジェクトメンバーにいる場合は、発言権をあたえてはいけません。また、自由に動く裁量を極限まで削りましょう。与えるマシンのメモリは4Gを上限として、ソフトウェアのダウンロードは禁止にしてください。
これを怠ると、自分のマシンで継続的インテグレーションの環境つくり始めたりするのでなんとしても防ぎましょう。

なんとしても、この層の「自動化したい」という心をへし折ってやりましょう。

自動テストのつぶし方

計画について

正直、どんな技術者を雇っても計画さえ適切に自動テストを潰す方向に向いていれば確実につぶすことが可能です。

無理な目標を立てる

テストの自動化を導入するセオリーが「有効そうなところの、できるとこから」なので、ここでは、いきなり完璧を目指しましょう。

単体テストのカバレッジは100%を必須とし、やるのが難しいGUIの自動テストやスレッドの自動テストを積極的にやりましょう。重要度の高いところだけとかいう甘えを捨てさせるために優先度は全てが最優先でトリアージをさせないように心がけましょう。

是非、完全で完璧な自動テストを目指しましょう。きっと自滅してくれます。

準備期間は与えない。

準備期間は与えずに自動テストを始めるようにしましょう。
当該プロジェクトにあった自動テストの方法や、共通的なテスト用のユーティリティの作成、参考となるテンプレート的なテストの作成、要員の教育を実施する余裕を削ります。

この際、毎日、何件テストを作って何件消化したかを報告させるようにして遅延が発生したら詰めるようにしましょう。これはコッソリ目先の進捗を犠牲にして共通的なテスト用ユーティリティを作る不届きものを排除するためです。

全員が同時に始める

テストコードの書き方のパターンがなるべくバラバラになって、制御が困難になるように
テストコードを書くタイミングがなるべく同時になるようにします。可能であれば、経験のない人間が最初にテストコードを書き始めるようなスケジュールをひきましょう。そして、経験のある人間がテストコードに着手できるタイミングを可能な限り遅らせます。

これにより、効果的なテストコードの書き方のテンプレート作成を防止し、仮に、作成できたとしても状況を手遅れにすることが可能になります。

新しいぶどう酒は古い革袋に入れる

テストの自動化を行うからといって、従来の管理方法を変えてはいけません。

実装→単体テストのチェックリストの作成→単体テストの実施…これらの順番は重要で、実装しながらテストを書くなどという不届きなことをさせないために、この順番は守らせましょう。

また、単体テストのチェックリストは必ず作成を義務付けて、バグの発生件数の指標やステップ辺りのテスト件数も従来のものから変えてはいけません。

新しいぶどう酒は古い革袋に入れて、ぶどう酒も手袋も無駄にしてやりましょう。

動かないテストコードを作成する

正しいかどうかよくわからない大量のテストコードは、確実に自動テストをしない方がマシという状況に我々にもたらしてくれます。自動テストの文化を潰すには動かない、あるいは動いているふりをするよくわからないテストコードを大量に作成することです。

テストコードのレビューを防ぐ

テストコードの作成の経験のない人は自分の環境でないと動かないテストや、特定の秒数じゃないとうごかないテストコードを書いたり、そもそもxUnitの検証にあたる箇所を目視でおこなったりします。

これらはテストコードを読むと簡単に検知できますが、そういう工数を削りましょう。
これにより動かないテストコードあるいは動いているふりをしているテストコードを大量に作成できます。

GUIのテストケースで不安定にさせる方法

そもそも、GUI操作でのテストの自動化が不安定になる傾向があります。
さらに不安定にさせるには「Windowsの画面操作を自動化しよう」で書いたことを参考に不安定な操作方法を模索しましょう。

• 自動操作ツールが言っている「だれでも簡単に自動操作ができます」という営業文句を真に受けよう！
  • この手のツールはGUI操作をレコーディングし、操作内容のスクリプトが自動生成されることがあります。これは一見それっぽく動きますが、よく確認しないと不安定な動作の原因となります。
• コントロールの特定には座標を積極的に使う
  • 解像度の違いなどで簡単に不安定にできる
    • オブジェクトで特定すると安定するので、その機能がないツールを選定する
• 画面の切り替えにはSleepを積極的に使うようにする

定期的にテスト実行をしない

デイリービルドなどの定期処理にテストの実行を組み込まないようにしましょう。
組み込んでも何が合格して何が失敗したかわからないようにしましょう。

これにより、動かないテストコードが作成されても検知できないくなり、動かないテストが大量に増殖していきます。

定期的にテストが実行できない状況をつくる

定期的にテストは実行しないとか決めても、勝手に定期的にテストを実行しだす奴はあらわれます。
彼らの暴挙を防ぐには定期的にテストが実行できない状況を積極的に作りましょう。
定期的にテストが実行できない状況とは以下のような状況です。

• 特定の環境でないと動作しないテストを作る
• 時間のかかるテストを作る
• リソースを大量に消費するテストを作る

これらは、通常回すテストと、頻繁に実行しないテストを分けるというような優先順位をつけて自動テストを実行することで回避されてしまいます。

これを防ぐには、テストコードを実行する場合は全て実行しなければならないとか、全てが優先度が高いとかいうトリアージができないルールでも作ってしまえばいいでしょう。

完全で完璧を求めるほど、逆にテストコードは実行されなくなっていきます。理想的な自動テスト推進派の顔を演じて、自動テストを叩き潰してやりましょう。

テストコードのメンテナンスにコストをかけない。

テストコードは簡単に動かなくなります。
たとえば、共通処理が変わっただけで動かなくなったり、WindowsUpdateを実行したりして動かなくなったりすることがあります。

是非、目先の作業を優先してテストコードのメンテナンスを行わないようにしましょう。
これにより、動かないテストコードが増殖します。

プロジェクト終了後

どんなに旨く失敗させた後も油断はしないでください。
実は失敗した際の情報というのは、次の成功につながる情報が含まれていることがあります。

ふりかえりなどのプロジェクトの反省はもってのほかですし、失敗したテストコードなどの資産などは削除するか、圧縮して他の人間が簡単に閲覧できないところに置いて別チームが活用できないようにしましょう。

俺たちは、一分前の俺たちより進化する、
一回転すればほんの少しだけ前に進む、
それがドリルなんだよ！！

…のように穴堀シモンのような事を言い出す奴がいるので、確実にリセットして何度でも同じ失敗をするように導きましょう。

そもそも自動テストをさせない戦略

xUnitの自動テストを防ぐ方法

ツールをダウンロードさせない

EclipseやVisualStudioに最初っから、単体テスト用のフレームワークが入っていることが多いのでxUnitのフレームワーク自体を使用不可にするのは難しいです。
しかしながら、モックやスタブ用のライブラリはダウンロードしないと入手できないので、これを防ぎましょう。
しかし、ダウンロードを防いでも自力で作り出す奴がいたりするので油断はしてはいけません。

xUnitでテストしづらいルールにする

xUnitのフレームワークでテストができなくなるルールとしては以下の通りです。

• ローカル変数を含めてステップごとに変数の変化をテスト結果に求める
  • 入出力だけ確認するのは「ゆとり」。こころをこめてローカル変数の内容をエビデンスとしてのこす
• IDEのステップごとの実行中のスクリーンキャプチャを取るようにする
  • 実際、パスが通ったかどうかを心を込めたスクリーンキャプチャで確認する

GUIで自動テストさせない方法

そもそもGUIの自動テストは難しいので手を下す必要はないですが、確実に根絶したい場合は以下を参考にしてください。

Webアプリケーション

マルチブラウザ対応の場合、Seleniumをダウンロードを禁止すれば、たいてい旨く防止できます。
InternetExploreが対応の場合、VBAやWSH,PowerShellで書けてしまいます。
基本これを防ぐ方法は難しいですが、Officeのマクロ、WSH,Powershellについてはセキュリティー方面で攻めてみればワンチャンあるかもしれません。

Windowsアプリケーション

基本的にUIAutomationを使用してVBAやPowerShellでなんとかなってしまうので、UIAutomationを使用するためのオブジェクトの構造をしらべるinspectのダウンロードを禁止することでなんとかしましょう。
inspectがなくても自作してくる狂人がいるので、これはOfficeのマクロ、WSH,Powershellのセキュリティー方面で攻めてみればワンチャンあるかもしれません。

さいごに

今回は自動テストをさせない方法を考えてみました。
正直、どうやって実現するかというのを考えるよりは、頭を使わずに済んで簡単ですね。なお、本記事の内容はフィクションで、実践している組織は存在しないはずです。ないですよね？

なお、私は基本的に自動テストを導入したりテストコードを書いた方が楽と考える立場ですが、定期的にテストを実行したり、回帰テストをするという文化や能力がないところで、テストコードを書くのを義務づけてはいけない。
これだけははっきりと真実を伝えたかった。
いや、マジでその状況はテストコードが負債になるので、やんない方がマシです。