[ソース]Privateメソッドを合理的に(?)テストを可能にする考え方

4838 ワード

私の考えではありません...これは野熊学院のコメンテーターフクロウのアイデアを整理した内容です.
私たちが設計した何らかの方法が私有であることを考えてみましょう.
struct 가위바위보게임 {
    private var 승패결과: String
    
    func 게임실행() {
        ...
        ...
        승패결정()
        ...
        ...
    }
    
    private func 승패결정(왼손: Hand, 오른손: Hand) { // 테스트 어려움
        ...
        ...
        승패결과 =}
}
試験コードを記述する場合、このような非公開の方法(開示された게임실행()方法によって間接的に行われる可能性がある)は、単独で試験することは困難である.
単独でテストできない機能については、テストの柔軟性が悪く、信頼性が高いことが難しいため、可能であれば改善が必要になる可能性があります.
では、승패결정()の方法をテスト公開するにはどうでしょうか.
これにより、승패결과のパーセントが外部で任意に変更できるという副作用が生じる.テストのためだけにこの副作用を開くのは適切ではありません
副作用を起こさずに独立してテストできる方法はありますか?
他にも方法がありますが、テストする機能を「独立したタイプ」にする方法があります.
struct 가위바위보게임 {
    private var 가위바위보심판자: 심판자
    
    func 게임실행() {
        ...
        ...
        가위바위보심판자.승패결정()
        ...
        ...
    }
}

struct 심판자 {
    var 승패결과: String
    
    func 승패결정(왼손: Hand, 오른손: Hand) { // 테스트 가능
        ...
        ...
        승패결과 =}
}
private機能を個別のタイプとして作成し、このタイプのインスタンスをprivateとして実装します.가위바위보게임のゲーム結果は게임실행()の方法でしか変更できません.승패결정()の方法を独立してテストできます.