2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

テストを自動化するにあたっては、さまざまな問題が存在する。それらを簡単にまとめてみる。

そもそもテストを書けない

テストを自動化するには、テストを書かなければ始まらない。例えば、Aという操作をBに適用したらCの結果になるべきである、ということを記述する必要がある。

だが、さまざまな理由により、テストを書けない場合がある。

  • テストを書く時間がないからテストを書けない
  • テストを書こうとするが、そもそもテストケースがわからない
  • テストを再現性をもって書く方法が思い浮かばない

このような場合、テストを書くことができず、当然ながらテスト自動化に至ることができない。

テストをコードに起こせない

どうにかテストを書いたとしても、次の問題としては、テストをプログラムコードに落とし込まなければ、やはりテストの自動化は不可能である。

つまり、人間の目視でOK/NGを判定するような仕組みのままでは、テストの自動化はできないのだ。

チェックリストベースのテストだと、これが起きやすい。また、ブラウザの挙動をベースにテストをする場合においては、どのようにそれをコードに起こすかが非常に難しく、自動テストには大きな壁が立ちはだかることとなる。

テスト自動化の設定ができない

先ほどまでの手順で、テストの実行はできるようになったので、手作業でテストを実行することを指示すれば、テストを実行することはできる。だが、テストを自動化するには、自動テストのためのCI設定が必要になる。

その際ネックになるのは、CI環境におけるテストの指示のやり方やカバレッジの収集方法の記述などである。また、テスト稼働環境にかかるコストというのも、この段階でネックになる。このあたりの万難を排さなければ、やはりテストの自動化はかなわないことになる。

テストケースのメンテナンスができない

どうにかテストを書いたはいいものの、仕様変更や機能追加などにより、テストの追加・変更が必要になってくる。こういった際に、テストケースのメンテナンスができないと、テストケースに漏れや誤りが出てくることになり、コードの品質が低下してしまう。

であれば、もう自動化なんて無駄、という結論になりかねないので、テストケースのメンテナンスも踏まえた設計を心掛けなければならない。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?