システム開発においてバグはないか、意図通りの動作を確認するテストは必須の工程となっています。
テストというと、受け入れテストや単体テスト、結合テストといったプロジェクト管理寄りのテストを想像しがちですが、今記事ではエンジニア寄りのテストを整理してみたいと思います。

エンジニア視線でのよくあるテスト

エンジニア寄りのテストと言われて、どのようなテストが思い浮かぶでしょうか。
よくあるテストとして、テストごとの操作を記述したものをエクセルに記述し、１つ１つ手作業で実施したことがある人がいるかもしれません。
システムは人間が使うものである以上、UIに関わるテストなどは人間の手で行うことになるでしょう。

一方で、ITエンジニアにとって重要な考えかたとして、自動化できるところは自動化すべきです。

メソッド単位でのユニットテスト

自動化できるテストのなかで、効果の高いものとしてユニットテストがあります。
単体テストを英語に言い換えただけに見えるかもしれませんが、コーディングをする上でのユニットテストは異なる意味を持ちます。
ここで言うユニットテストとは、メソッドごとにテストを実施するものであり、有名な言語ではユニットテスト用のライブラリがあると考えて差し支えありません。
例としてrubyであればtestunit、PHPはPHPUnit、JavascriptはJasmineなどがあります。

ユニットテストの特徴としては、テストの実行動作の負荷が軽く、気軽に実行できるというものです。
一方でデメリットとしては、すでにあるシステムにテストを導入することが難しく、テストのためにシステムの一部を修正するといった場面もありえます。
ユニットテストを導入する最良のタイミングは新規に開発を行うときでですが、Webフレームワークの仕組みにテスティングフレームワークがある場合は、途中からでも比較的テストコードを書きやすくなっているかと思います（興味のあるかたは検索してみましょう！）。

実際に画面操作するブラウザテスト

これはWebアプリケーションで使えるテストとなります。
ブラウザの操作を自動化することで、省力化や変更をした際に何度でもテストを行うことができるようにする、というものです。
Webアプリケーションの場合、同じテストをIEやchromeなど複数のブラウザで試すことが前提であり、この部分を自動化することで効果を見込むことができます。
ツールで言うと、古くはJMeterやSelenium、最近ではPhantomJSなどJavascript製のものもあります。

実際のブラウザ操作を自動化するブラウザテストですが、デメリットもあります。
ブラウザを操作するぶんテストに時間がかかること、あるいはテストの修正に手間がかかるというものです。
仕様の変更に応じてテストも修正する場合、ユニットテストよりもテストコードの修正が複雑になることが多いようです。

まとめ

テスト自体は開発するシステムの価値を増やすものではありませんが、エラーの発生するシステムは誰にも使ってもらえません。
テストのやりかたを効率化することで、システムの価値を増すことに集中できるようにしましょう！

様々な分野で活躍するエンジニアが在籍するソリューション事業部はこちら

●Wantedly掲載情報(本当にやりたいことに辿り着きたい技術大好きエンジニア募集！)

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

●Wantedly掲載情報(Angular/Reactを極めたいフロントエンジニア大募集！！)