movePayment.js

// https://github.com/j5ik2o/ticket-price-modeling
// 解き方方針: 型で問題を解くよりも、料金表のように日本人の非エンジニアの人も読めて突っ込めるコード記述を目指す.
// 解き方方針： 配列でmap&sortの世界に引き込んで安い料金を選ぶようにする.
// 解いたのは "シネマシティズン" の場合だけ。

// TODO 引数を型にして呼び出しに制約を設けるかはあとで考える。
const movePayment =  (ticketType, timeTypes) => {
  var payments =
  {"シネマシティズン":
    {"平日〜20:00":        1000, 
     "平日20:00〜（レイト）":  1000, 
     "土日祝〜20:00":      1300, 
     "土日祝20:00〜（レイト）": 1000, 
     "映画の日":           1100}}

  // 見つからなった場合はあとで考える
  return timeTypes.map(timeType => payments[ticketType][timeType]).sort((a, b) => a - b).shift()
}

// ？からチケットタイプを返すはあとで考える
// システム時刻から映画チケットドメインの時間タイプを返すはあとで考える
// 文字列を型にするはあとで考える, 返す数値の型はあとで考える
describe("チケット料金", () => {
  describe("シネマシティズン", () => {
    it("平日〜20:00の場合は1000", () => {
      expect(movePayment("シネマシティズン", ["平日〜20:00"])).toEqual(1000)
    })

    it("平日20:00〜（レイト）の場合は1000", () => {
      expect(movePayment("シネマシティズン", ["平日20:00〜（レイト）"])).toEqual(1000)
    })

    it("土日祝〜20:00の場合は1300", () => {
      expect(movePayment("シネマシティズン", ["土日祝〜20:00"])).toEqual(1300)
    })

    it("土日祝20:00〜（レイト）の場合は1000", () => {
      expect(movePayment("シネマシティズン", ["土日祝20:00〜（レイト）"])).toEqual(1000)
    })

    it("映画の日は1100", () => {
      expect(movePayment("シネマシティズン", ["映画の日"])).toEqual(1100)
    })

    describe("時間タイプの条件が重なる場合について", () => {
      it("映画の日かつ土日祝〜20:00の場合は、安い映画の日が優先されて1100", () => {
        expect(movePayment("シネマシティズン", ["土日祝〜20:00", "映画の日"])).toEqual(1100)
      })
      
      it("映画の日より安い方のがあれば安いほうが優先されてる", () => {
        expect(movePayment("シネマシティズン", ["映画の日", "土日祝20:00〜（レイト）"])).toEqual(1000)
        expect(movePayment("シネマシティズン", ["平日〜20:00", "映画の日"])).toEqual(1000)
      })
    })
  })
})

// 感想 データ駆動のテストの方がドメインを的確に捉えて記述できると思われるが調べるのを忘れた。
// 感想 配列＆ハッシュむき出しでDDDらしさはないが、読みやすいのでは？
// 感想 表で表現できなくなった時に破綻するなぁと。一方、表現できない複雑さのあるものを理解して使えるのかも気になる。