機能としては、ログをローテーションする、というものだが、設計書に、ローテーションする、と書かれても、So what?ってなる。ローテーションするとは、どういう事なのか、噛み砕いて説明する必要がある。一言、ローテートする、と書かれても、具体的にどうやってローテートするのかを考えられていないことを自白しているようなものだ。

記述を基本設計らしくブレイクダウンするためには、幾つかの問いに答えていく必要がある。

・ログとは何か？

→夜間バッチで吐き出されるログファイルを指している。今回の案件で言うと、どのログファイルが対象か、は特定されているので、その特定のログファイルに限定して処理を行う必要がある。

⇒ローテートをどうやって実現するか、の前に、対象のログファイルを特定する必要がある。

⇒（How?）iniファイルに定義する。

⇒ファイルを読み込む処理を記述。

　エラーの場合も記述。

・ローテートとは何をするのか？

→過去5日分のログを保持し、それ以前のログについては削除をする。

⇒過去5日分、はどうやって判断する？

⇒ファイルの更新日時かファイル名（※）から判断することができる。今回は、後者でいく。また、この機能は夜間ジョブとして追加するが、同ジョブが同日に複数実行された場合は、同日で複数ログが吐かれることになるが、その場合は、5日分、にカウントされない。同日日付で複数のログファイルが生成されることになる。

※ファイル名について

今回の対象ログには、2種類あって、①XXXX.log　とログ名に更新日時が記載されないログ。今回の要件として、ファイル名に更新日時をつけてほしい、とのこと（_yyyymmddHHMMSS）。②XXXX_yyyymmddHHMMSS.logと既にログ名に更新日時が記載されているログの2種類ある。

これくらいの粒度で、何をやるか、を書き出さないと、詳細設計に落とせないし、結合テストも出来ない。

○参考

https://pm-rasinban.com/bd-write

2019-11-21

単体テストTips

単体テスト

久しぶりに新規開発をして、ガッツリ単体テスト仕様書を書くことになった。

レビュー指摘を踏まえて、ここに要点をまとめる。

１、マトリックスで考える

⇒基本的に、T/Fで考える。詳細設計書を忠実に書き起こしただけで満足しない。

設計書には、ifの場合の話しか書いていなかったとしても、ケース上は、if文を通らないパターンも表現されないといけない。

if文があれば、if文に入る/入らないの2ケースが必要。Aのケースがあれば、Bのケースを考える。C,D,E…どこまで考えれば良いのか整理する。テスト条件が複数必要な場合は、その条件数分、マトリックス化して、ケースに落とし込む。テスト実施不可のケースがあったとしても、マトリックス上表現はしておいて、グレーアウトすると網羅性を担保できる（※）。

※この点について、前に別案件でクライアントレビューで指摘を受けたことがあった。テストケースレビューする前から、鼻からグレーアウトするくらいだったら、そもそもケース切らないで良いんじゃないの？と言われたことがあった。しかし、網羅性を担保できなくなる、と言って、食い下がったことがあった。お客さんによっては、不要と言う人もいるようだが、そこはこちら側の考えを通して良いと思った。

２、曖昧な表現は避ける

⇒テスト実施者が迷う表現は避ける。詳細設計書がちゃんと書けてれば倣うだけでいいが、そうじゃない場合は、翻訳が不要なレベルに落とし込んだ表現を使用する。文脈を捉えていないと理解できない表現はダメ。

〇ハマったところ

for文についての記述で「〇〇へ戻る。」と、詳細設計書に記載があって、そのケースを書き起こす際に、該当のデータの次のデータがfor文に入ってくるログを確認することを期待結果とした。その際の表現として、「次のレコードを確認する」としてしまったが、「次のレコード」って、曖昧さが残ってしまっている。。ここは、SVに確認後、内容を更新する。「〇〇が△△になる」って表現だったら、〇〇を確認すれば、それで良いけど、「〇〇へ戻る」という表現等の場合、その記述自体に中身が無いから、確認のしようが無い。だから、その次に起こる事象を持って確認する、というのは正しいのか？要確認。

2019-11-20

シェルの新規開発

開発

夜間ジョブが吐き出す、ログをローテーションするシェルを新規開発。

UNIXと言えば、影響調査や見積でgrep調査ぐらいしか触ったことが無くて、シェルは初めてでとても苦労したが、その時の備忘録的にメモ。ちなみに、bash。

○変数？名

$数字→「ls」で表示される項目。左から1、２、３……。6が確か、更新日時（年月日）、7が確か更新日時（時間）。

○正規表現

[ ]（かっこ）→orの意味。

ex) [:-]→「:」か「-」

○デバッグ

bash -x シェル名→一気に変数の中身もばらした上で出力してくれる。ソースをいじらなくて良いから、テストで使える。

trap 'read -p "$0($LINENO) $BASH_COMMAND"' DEBUG→ソースに埋め込む必要があるから、実際のテストでは使えないけど、ステップインできる。

○ハマったところ

・変数の表現→{ }をつけるつけないで、処理が通る通らない、ってことがあった。

・ファイルの並べ替え処理の実装方法で詰まった。ファイル名の「_yyyymmddHHMMSS」の降順で並び替える必要があったんだけど、ずっと「ls」で検索してたが、良い方法が見つからなかった。が、「find」と「sort」を使えば、出来た。

○感想

結局、プログラムに出来ないことは基本的には無い、ということを再確認したけど、やっぱり、具体的な実装方法は知らないとできない。正規表現で検索対象を指定する処理と、for文を一文で書ける、なんていう想像力は、シェルを触ったことがある人じゃないと持っていないんじゃないか？

設計の段階から、プログラムレベルでイメージが湧かないとキツイ。正規表現周りの部分が、具体的にどうやって実装するのか、自分一人ではイメージ出来なかった。今回は有識者によるサンプルコードがあったから、まだ助かったけど、これがゼロベースでやれ、って言われてたらもうあと2人日くらい必要だったと思う。

tottimotottiのブログ

コンサルときどきエンジニアの銭湯巡りランナーの備忘録。

No.2高砂湯

No.1藤の湯

UNIX雑記

詳細設計Tips

基本設計Tips

単体テストTips

シェルの新規開発