돌연변이 테스팅

돌연변이 테스팅

우선 돌연변이 테스팅은 명령문( <, <=, == 등) 에 대해 변경을 가하여 테스트하는 기법으로 보인다.

https://www.reddit.com/r/programming/comments/1fub9dw/what_is_mutation_testing_and_why_you_should_use/?tl=ko

최근 회사동료와 같이 프로젝트를 진행하며 작성한 테스트 코드에서 힌트를 얻었다.
enum상수의 추상 메소드를 테스트하는 것이었는데, 반환타입을 인터페이스의 구현체 중 아무거나로 변경하여 테스트를 수행해도 깨지지 않았다는 것이다.

아래는 sample code이다. 이렇게만 test case을 작성하진 않겠지만, 예시임을 이해하라.

class CarTest {

    @Test
    fun testCarName() {
        val kia = Car.KIA.make()
        val honda = Car.HONDA.make()

        kia.name shouldBeEqual Car.KIA.name
        honda.name shouldBeEqual  Car.HONDA.name
    }
}

enum class Car {
    KIA {
        override fun make() = Kia(this.name)
    },
    HONDA {
        override fun make() = Honda(this.name)
    },
    ;

    abstract fun make(): Cars
}

interface Cars {
    val name: String
    fun isDomestic(): Boolean
}

class Kia(override val name: String) : Cars {
    override fun isDomestic() = true
}

class Honda(override val name: String) : Cars {
    override fun isDomestic() = false
}

 

테스트에 대한 경험이 충분하다면 위 테스트 케이스가 잘못되었거나(부족) 하다는 것을 쉬이 알 수 있을 것이다.
나는 이 테스트 코드를 보고, 돌연변이 테스팅 기법이 떠올랐다.

만약 Car enum class의 HONDA 상수의 make() 반환 클래스를 Kia 로 변경하여도 위 테스트는 문제 없이 동작할 것 이다.

enum class Car {
    KIA {
        override fun make() = Kia(this.name)
    },
    HONDA {
        override fun make() = Kia(this.name)
    },
    ;

    abstract fun make(): Cars
}

 

name property로 this.name을 던지고 있기 때문에, 올바른 상수의 name이 전달된다. 뭐, 단순히 conflict resolve의 실수라고 해보면 테스트 코드가 이를 커버하지 못했다고 볼 수 있다.

돌연변이 테스팅이 필요한 기법이다, 아니다를 말하기에는 사용해본적이 없어서 아쉽지만 적어도 이러한 기법을 알았기 때문에 위 테스트 코드가 부족함을 아는데에 도움이 되었다고 본다.