テストケース練習：複雑な純粋関数①
今回のような関数を「パイプライン型」とでも呼ぼうか。
関数型プログラミングっぽいよな。
仕様
code: ts
function calculateMonthlySalary(employee: Employee, attendance: Attendance) {
// この関数を実装する
}
interface Employee {
id: string;
baseSalary: number;
position: "staff" | "leader" | "manager" | "director";
yearsOfService: number;
hasDependent: boolean;
commuteCost: number;
}
interface Attendance {
workDays: number;
expectedWorkDays: number;
overtimeHours: number;
lateCount: number;
holidayWorkDays: number;
}
code: 処理内容.txt
計算ルール
1. 基本給計算
基本給をベースとする
欠勤日数に応じて減額（1日あたり = 基本給 / 所定労働日数）
2. 役職手当
staff: 0円
leader: 20,000円
manager: 50,000円
director: 100,000円
3. 勤続手当
3年未満: 0円
3年以上5年未満: 10,000円
5年以上10年未満: 20,000円
10年以上: 30,000円
4. 家族手当
扶養家族あり: 15,000円
扶養家族なし: 0円
5. 残業代
平日残業: 時給の1.25倍
時給 = 基本給 / 160時間（月平均労働時間）
6. 休日出勤手当
1日あたり: 日給の1.35倍
日給 = 基本給 / 所定労働日数
7. 遅刻控除
1回あたり: 1,000円
8. 通勤手当
そのまま加算
実装した関数
テストケース作成戦略
作ったコードのcalculateMonthlySalaryを見てもらえればわかるようにシンプルな処理になってる。
salaryというデータに順番に処理を行っていってるだけ。
calculateMonthlySalaryでは複雑なことはしてない。
こういう時は、細かい処理とテストは各々に任せてしまう。
calculateMonthlySalary自体は、よくあるシナリオを数個テスト書いておけばいい。
今回の場合は、それが十分な回帰テストになるはずである。
二度同じapply関数を適用したり、新しいapply関数を作って入れたりしても、回帰テストがエラーを吐いてくれるのでリスク低い。
こういう関数を「Pipeline型」と呼ぶことにしようかな。
こういう時は、細かいテストは全て内部関数に任せつつ、メイン関数ではハッピーパステストを数個しておけばいい。多分。
似たようなパターンの関数を見たら、こんな感じでテストすれば良いかと思われる。
メイン関数にif文がないというのが大きいかもしれない。もしかしたら。
いや...
普通にメイン関数用のテストケースだけ作って、内部関数のテストは無視でもいいかもしれない。
そんな大量のテストケースが生まれるわけでもなさそうに見える。
う〜〜ん。今回のケースの場合は、どっちでもいいように思えてきたな。