はじめに

この記事はZOZOテクノロジーズ #2 Advent Calendar 2019の17日目の記事となります。
昨日は @sashihara さんによる2年間チームで毎週1on1に取り組んでわかった3つの効果でした。

今年、ZOZOテクノロジーズでは全部で5つのAdvent Calendarが公開されています。

ZOZOテクノロジーズ #1 Advent Calendar 2019
ZOZOテクノロジーズ #2 Advent Calendar 2019
ZOZOテクノロジーズ #3 Advent Calendar 2019
ZOZOテクノロジーズ #4 Advent Calendar 2019
ZOZOテクノロジーズ #5 Advent Calendar 2019

様々な記事が投稿されていますので、皆様お時間有りましたら是非ご覧ください。

本記事の目的

新卒エンジニアで入社した自分はお恥ずかしいことに、今まで単体テストと呼べるものを行ったことがありませんでした。
このままではまずいと思い、単体テストなるものにチャレンジをしてみることに。
そこで、「レガシーコード改善ガイド」という本を読んで単体テスト・テストコードの重要性を理解したので、この二点に着目してみました。
それを踏まえて自分なりに今の環境でできるVBSの単体テストをやってみたので考察を載せます。

前置き

「レガシーコード改善ガイド」によると、レガシーコードというのは、 テストで保護されていない扱いにくいコード と定義されています。
テストで保護されていない扱いにくいコード がなぜ悪いのか？（エンジニア経験のある方ならなんとなく感覚でわかると思います）
「レガシーコードからの脱却」内の言葉を借りると以下です。

レガシーコードとは、バグを多く含み、壊れやすく拡張が難しいコードを指します。
このようなコードの保守と管理には多大な労力がつぎ込まれることになります。
しかも一度作ってしまったレガシーコードの質を上げるには、初めから質の高いコードを作るよりも膨大なコストがかかります。

ざっくりと聞くだけでも課題が山積みですね。。。
「レガシーコード改善ガイド」ではそんなレガシーコードを改善する・予防するためにはテストコードが必要と述べられています。

このことからテストコードを用いて、単体テストをやってみよう！と思い立ち、実際にやってみました。

環境

自分が普段扱っている言語はVBSですが、VBSには有用なテストツールがないので自前でテストコードを書いています。

テストコードを用いた単体テスト

実践してみたテストコードの一部を抜粋。（内容は多少ぼかしてます）
これが単体テストと呼べるかも怪しいですが、、、

Call IsOverTargetAmount_test()
Sub IsOverTargetAmount_test()
	Dim amount : amount = 4999
	' Dim amount : amount = Empty
	' Dim amount : amount = ""
	' Dim amount : amount = NULL
	' Dim amount : amount = "abc"
	' Dim amount : amount = -7000
	' Dim amount : amount = 4999.9999
    response.write "amount : " & amount & "<br>"
    response.write "IsOverTargetAmount : " & (IsOverTargetAmount(amount) = False) & "<br>"
End Sub

Function IsOverTargetAmount(ByVal amount)
	IsOverTargetAmount = False

	If Not (IsNumeric(amount) And amount <> "") Then
		' 引数が数値かどうかバリデーション
		Exit Function
	End If

	If amount >= 5000 Then
		IsOverTargetAmount = True
	End If
End Function

' ▼実行結果
' amount : 4999
' IsOverTargetAmount : True

単体テストにチャレンジしてみての考察

可能な限り、I/Oがシンプルなものにする
- I/Oが複雑なものはテストコードが書きづらく、レガシーコードになりやすい
- 最低限Iは複雑でも、Oはシンプルだとテストが楽（個人的理想はBool値）
バリデーションは以下の値に注意する
- 変数の型（数値なのか、文字列なのか、オブジェクトなのか）
- 数値の場合、少数や負の整数、型の限界値（INTなら -32,768 ～ 32,767）、境界値（不等号の周辺値）
- 空文字、Empty、NULL、Nothing 等の特定のイレギュラーになりうる値
テストコードはあくまで書いてあるコードが正しいことを確認する
- 仕様（ビジネスロジック）が正しいかどうかはテストコードでは確認できない
DB側は単体テストが難しい、、、
- DBとの接続が発生する場合、モック的なテストデータが必要
- 準備が手間
手戻りが手前になる
- 結合テストフェーズになって、手戻りが発生すると厄介なのでそれを防げる
そもそも他と依存関係のないコードでなければ単体テストとは呼べない（単体テストをするのが難しい）
単体テストにはホワイトボックス・ブラックボックステストがある
- Ref : 単体テスト(ユニットテスト)とは
- ホワイトボックスではコードが正しいことを確認する
  - ホワイトボックステストのカバレッジについてはこちらを参考に
  - Ref : ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について
- ブラックボックステストでは仕様が正しいことを確認する
  - 仕様の確認なので人の目によるレビュー等が必要

最後に

今回テストコードを書いて単体テスト（ホワイトボックステスト）を行ってみた感想としては、少なくともやる意味はあると思いました。
後戻りする機会が圧倒的に減ることメリット、主観的に完成度は上がると感じました。
しかし、プログラムの書き方や言語によってテストのハードルはかなり差が生まれるというのも実感しました。
単体テストの自動化できる言語もある中、自分でテストコードを書くのは正直工数が増える面があると思います。
また、テストのエビデンスの残し方やテストコードの管理方法等も考えなくてはなりません。
まだまだ課題は山積みですが、今後のサービスの成長に合わせて、微力ながらレガシーコード改善に取り組めればと思います。
（ただ、レガシーコードでもサービスとしてここまで成長できたことは非常に尊敬しています。）

明日は @mitanih さんが記事を書きます！ぜひご覧ください！