4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【やってみた】Shellスクリプトの開発をテスト駆動開発で進めてみよう。

Last updated at Posted at 2022-06-04

そびえ立つウォーターフォール

なんだか、ウォーターフォールってイナズマイレブンの技っぽいですよね。

最近、WBSをつくる際に脳死でウォーターフォールっぽく線を引いていることに気づきました。
アジャイルでやるべき!とかウォーターフォールでやるべき!とか、
そういう議論は置いておいて、
流行りの手法にせよレガシーな手法にせよ、一長一短あって、
まだまだ新米の私は、兎に角、理論を経験に昇華させ、その特性を味わっていくしかないよなぁと
ぼんやりと考え、少しウォーターフォールから離れてスケジュールを作成してみました。

具体的には、
V字モデル(詳細設計→プログラミング→単体テスト→結合テスト)を採用していたところを、

① 結合テスト計画を詳細設計の直後へ
② テスト駆動開発(TDD)でプログラミングと単体テストを並行実施

というような考え方で以下の流れに変えてみました。

詳細設計→結合テスト計画→単体テスト/プログラミング→結合テスト

(といいつつも、大きな変更ではない気もしますが)
V字モデルでは詳細設計書があればIT仕様書はいらないとかいってますしね、

色々と恩恵とリスクを見つけたので、メモしておこうと思います。

① 結合テストの計画を前倒しした効果

これは、恩恵が半端なかったです。

テストケースを作成するところまで実施するのですが、
詳細設計書の抜け漏れの検知はもちろん、
発生しそうなリスクに対応するために設計自体に柔軟性のある設計を意識することができ、
セルフウォークスルー的なQA活動ができました。

オライリーのDesign it!でも、曖昧性の原則として
最低限の設計をしてFeedback Loopを回す中で、アーキテクチャを成長させていくべきと述べられていますが、
がちがちに縛った設計を回避することができたのは、詳細設計と結合テスト計画を近づけた効果でした。

とはいえ、リスクがないわけではないです。
テストケースをあれこれ掲げすぎると、テストケースに依存した設計になってしまいますし、
意図した効果と正反対のリスクを抱える危険性もあります。この辺はバランスが大切ですね。

② テスト駆動開発(TDD)でプログラミングと単体テストを並行実施

ただテスト駆動開発を実践しただけなんで、わざわざ書くのも恐縮ですが。。。笑

とはいえ、シェルはオブジェクト言語たちと違って少し特異なコードの書き方になります。
(変数のスコープとかまじでわかりにくいし。。長くなるし。。)

私は、テスト用スクリプトと開発コードのそれぞれを準備し、
テスト用スクリプトで開発コードを読み込み、開発コード上の関数を呼び出す形で単体テストを実施し、TDDっぽく進めました。

良かった点を列挙すると。。。

・テストする機能毎でテストケースを書くことで、関数が定義しやすかった。
→ 関数作成すると、あれも関数化したい!これも関数化できる!とか迷った結果、可読性の失われたコードができがちなんですが、機能ごとにテストすることを決めてプログラミングに入ったので、それに合わせた関数を作成するだけでいいので、切り分けやすかったです。可読性もそこそこ担保で来ている気がします。(過去のものよりは圧倒的に読みやすい。。)

・テストコードが出来上がり、リグレッションテストを行いやすくなった。
→ テスト用スクリプトを残しながらワークが進んでいくので、最終的にはテストコードが残ります。出力された結果も比較可能な形にしておくことで、リファクタリングや仕様変更でコード修正があった際にテスト用スクリプトを実施して、結果比較すればリグレッションが完了するようになりました。将来的な工数削減が有難い。。

・ 新人用の勉強スクリプトができた。
→ これは完全な副産物です。(笑)
一気にすべてのコードを渡すよりも、レベルに合わせて関数とテストコードを切り出して渡すことで、段階的にシェルの書き方やコマンドを学習していってもらえるなぁと思っています。特に、テストスクリプトがあれば、それをいじりながらハンズオンで進められますしね。(小さい関数のリファクタリングなんかもいいかもですね。)

リスクの方は、TDDでよく語られているものを意識していただきたいです。
特に、テストを書くことが目的になってしまいそうな危険性はあります。
入出力を意識して、テスト設計にできるといいかなぁなんて思います。

全体を振り返って

全体を通して、ウォーターフォールで線を引いた時と比較して、
スケジュールが10日くらい前倒しできました。

結合テストの計画を事前に実施しておいたおかげで、
スケジュール自体の見通しが明るくなったことと、テストの準備をちょこちょこ進められたのも、
全体のワークロードを通して負荷を減らすことができたなぁと思います。

とはいえ、前述したようにリスクもありますし、検討しきれていない部分も多々あります。
これから先も、経験していく中で自分の中の成功ファクターとして昇華できるようにしたいなと思います。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?