ふくすく

この記事はアドベントカレンダー、ソフトウェアテストの小ネタの 12 日目の記事です。

ドキュメントもテストも存在しない。あるのは動いているコードと、それを何とかしようとした先人の努力の跡だけ。そういった際に、ユニットテストを使って試行錯誤しながらリファクタリングができたので、小ネタ程度に提供できればと思います。

正しく機能しているかどうかは、動かしてみないと分からない。

顧客が望んでいる機能は、バグが混ざったものが入っているかもしれない。

ロジックを 1 から作り直せたら楽かもしれないですが、リスクと天秤にかけるとリファクタリングをするしかない。

バージョン管理（ローカル管理できる Git が好ましい）と静的解析ツール（Lint 系）とドキュメント類出力ツール(JsDoc 系）とユニットテストツール(Mocha、JsUnit 等)があると便利でした。

JsDoc で API リストを生成してみましょう。出ればラッキーです。

目安程度に覚えておきます。

静的解析ツールでいい感じに修正しましょう。

Linter と Prettier を入れておくと便利でした。

共有しましょう…。ワンクリックですよ…。

省略語絶対ゆるさない状態だったので、eslint-plugin-unicornを追加で導入しています。Prevent abbreviations を true にすると省略語もチェックしてくれます。

テストを割と抽象度の高い感じに書いておいて、修正前後のインプットとアウトプットを定義しておくと便利です。（ユニットテストツールを使ってるだけで関数を結合させているような…そういう抽象度の高いやつです。

VSCode であれば、単語一斉検索と置き換えができますが、たまに見落としが発生します。

置き換え前後のテストはあった方が無難です。（1 ヒヤリハット

ユニットテストを観測棒のように使って、変数を１つの機能に分解していく段階です。

観測棒というのは、プローブ的な何かで未知の領域を観測するために計測機器が付いた棒をイメージしてほしいです。

プロセスを取り出す際にそのプロセスがどういうロジックで動いているのかを知るために使う。処理を中断したりやコンソールで確認することもできるが、繰り返し確認する際には、予め評価用にコードを書いておいた方が早かった。

こまめにバージョン管理しつつ、大胆に関数を取り出していく。

mocha が導入できるならmocha sidebar が便利でした。

こいつは設定してあげると、assert 部分を一覧にして一括実行や、コード上にテスト実行ボタンが表示されるので、ちまちま CLI から打たなくていいので良かったです。

グローバル変数が汚染されていると、値が飛び回る…

引数に設定していない値が操作される副作用はユニットテストと相性が悪い。

極力、返り値と引数で値をやりくりした方がいい派ですが、どうなんでしょうか。

実装する時間とテスト書く時間が４：６程度になってます。

単純に見ると工数１．６倍のように見えなくもないです。繰り返しできるから、保守工数の先取りとは言えなくはないんですが。

テストケース書くのがもっと省エネ化出来たらいいんですが…（シナリオ部分は表を書き出して、配列として出力する感じ）

ユニットテストは役目を終えるまで、嫌な顔せず、ひたむきにテストを実行してくれる。

ユニットテストコードこそが、自明に関数を定義している心強い存在であり、信頼できる友と言っても過言ではない。（過言

繰り返し繰り返し、仕様が変更されるまで、けなげにやってくれます…

（ユニットテストいいですよ…皆さんも導入しましょう…

現場からは以上です。

リファクタリングに便利なユニットテストと便利プラグインたち