ワンライナーときちんとしたプログラムとの中間のサイズのプログラムを書かないといけないことがあると思う。使い捨てではなく、継続的に使われるちょっとしたプログラムではあるのだけど、たかだか数百行みたいな、どうってこともないプログラムだ。あるいはきちんと育てるつもりのプログラムの開発の初期段階かもしれない。
こういう小規模なプログラムも自明ではないロジックが入っていたりするので、自分の想定しているとおりに動いているのか、小さい単位でユニットテストを書きたくなるのは普通だと思う。
しかしそういう小さいプログラムに対して、きちんとしたユニットテストのフレームワークを持ち込むのは相対的に大げさだったりする。ユニットテストのファイルをコピーしてきてそれをインクルードして、ビルドファイルにユニットテストをコンパイルするターゲットを足して、などというのはちょっと面倒だ。それに、フレームワークを使うと、コードを読む他のプログラマにもフレームワークについての知識があることを前提にすることになってしまう。
ユニットテストの本質は、自分が確認したいと思っていることを小さい単位で実際に実行して確認することだ。その目的さえ達成できればそれ以外は言ってみれば細かい話だ。
第1引数と第2引数を比較して、違ったらエラーを表示して終了する関数を自分で書くのは簡単だ。数行で書ける。小さなプログラムではそういうものを自分で書いてそれをユニットテストに使えばよい。読むのも書くのも簡単だし、大規模な依存関係を持ち込むよりはそちらのほうが簡素でよいと思う。
ユニットテストは別に独立したプログラムである必要もない。1ファイルにプログラム本体とテストを書いて、ある引数が渡されたときだけテストを実行するといった手法を取ることもできる。
とにかくなんでもいいから、自分が確認したいと思っていることが確認できればよい。一番よくないのは面倒だからテストを書かず闇雲に手でテストするというやり方だ（別にそれできちんと動けばいいが大抵時間の無駄になる）。
プログラムが成長してきたらそれなりのやり方に切り替えるほうがよいだろう。フレームワークは確かにいろいろ便利なものを提供している。しかし最初から「きちんとした」やり方を採用する必要はない。必要に応じて途中で切り替えればよい。