変更点に対するテストの考え方

はじめに

テストってどうしても抜けが出てきてしまうものですよね。

抜けもれなく!網羅的に! などとよく言うものですが完璧な人間でない限りは難しいです。
(それでも経験から精度はあがっていくものではありますが。)
特にも作成中のテストよりも、稼働中システムに対する変更というのには非常に気を使う必要があります。
この変更点に対してのテストの考え方について記載したいと思います。

変更点をテストするのは当然である

簡単な例を取り上げます。

例えばフォーカスアウトしたときにカンマ編集するようにしてほしい。 こういった要求を受け、(以下例)

focusoutイベント((obj) => {
 obj. value = obj. value. replace(/, /g,"")
}) 

focusinイベント((obj)=> {
 obj. value = obj. value. toLocaleString();
})

こんな感じのコードを組んだ時にこの2つのイベントについてテストしますよね。 これは新人だろうが、アルバイトだろうがこれはやると思います。

そんな中で例えば

focusinイベント( (obj) => {
 obj. value = obj. value. replace (",","")
})

こんなコードを作っていて、100万単位が入力されたときにうまく動かない! というのはテストの中で検知されるのかなと思います。

大事なのは変化点

見落としがちなのは変化点です。
上記例にてobjのvalueを参照しようとしていたメソッドなどではこれまで数値として取り扱いできていたものが、文字列になってしまう変化がうまれます。
こうなってしまうと例えば加算を行っていた場合、文字列結合になってしまうなどの弊害が発生します。

これは変化点をちゃんと検討して、参照しているメソッドの検証をすべて行っていないといけませんよね? こういった変化点の検討・検証を行うというのは経験不足なエンジニアは見落としがちなものとなります。

終わりに

ここでは簡単な例を取り上げましたが、レビューアはこういった変化点の検討ができているのか? という観点でレビューしてあげなければいけないなと思います。
デグレードが多くて困っている! などの技術者の方、後輩をお持ちの方の参考になれば幸いです。