mutation-testing

7 posts

Mutant가 무엇을 바꿨는지 모를 때 Surviving Mutant를 죽이는 방법

Mutation testing이 survivor를 찾았는데, 그 mutation이 도대체 무엇을 하는지 전혀 모르겠다. Mutant를 먼저 이해하지 않고도 올바른 테스트를 작성하는 단계별 방법이다.

Mutation testing 리포트는 survivor로 가득 차 있고, 그중 최소 하나는 도저히 이해할 수 없는 상태다. 도구는 47번째 줄의 를 로 뒤집었거나, 전체 조걸문 블록을 로 바꿨거나, 테스트 대상인지도 몰랐던 문자열 리터럴을 mutate했다고 말한다. diff를 세…

인증 코드는 90% mutation coverage가 필요합니다. 문자열 유틸리티는 아닙니다.

전체 코드베이스에 단일 mutation score를 강제하는 것이 왜 실수인지, 그리고 실제 리스크에 맞는 모듈별 임계값을 설정하는 방법.

전체 코드베이스에 단일 mutation score를 강제하는 것은 팀이 테스트를 싫어하게 만드는 최고의 방법입니다. 일반적인 저장소에 PIT이나 Stryker를 실행하면 같은 패턴이 보입니다: 인증 모듈은 40%를 기록하고, 문자열 유틸리티는 95%를 찍으며, ORM 계층은 60%대…

테스트는 통과한다. mutation score는 40%다. surviving mutant가 실제로 말해주는 것

code coverage는 안전하다고 말한다. mutation testing은 테스트가 대부분 장식이라고 말한다. surviving mutant가 이 간극을 드러내는 방법과 그것을 메우는 방법을 알아보자.

테스트는 통과한다. coverage 리포트는 87%라고 한다. 하지만 mutation score는 40%이고, 절반의 mutant가 여전히 살아있다. 그 40%는 코드가 망가졌다는 뜻이 아니다. 테스트가 망가졌다는 뜻이다. coverage는 테스트 실행 중 어떤 줄이 실행되었는지를…

Rust에서 뮤테이션 테스트는 통하지만, 컴파일 시간이 복수한다

cargo-mutants는 코드를 검증하는 척만 하는 테스트를 찾아낸다. Rust에서 뮤테이션 테스트가 어떻게 작동하는지, 무엇을 잡아내는지, 그리고 컴파일 시간 비용이 감당할 만한 가치가 있는지 알아본다.

라인 커버리지는 100%다. 모든 분기를 커버한다. 모든 함수를 호출한다. 그런데 누군가 가격 책정 로직에서 를 로 바꾸고 테스트를 돌리면, 테스트가 모두 통과한다. 이것은 이론적인 문제가 아니다. 테스트가 코드를 실행하지만 실제로는 동작을 검증하지 않을 때 벌어지는 일이다.…

뮤테이션 테스트는 4시간이 걸린다. 팀은 실제로 CI에서 어떻게 사용할까?

대부분의 팀은 매 커밋마다 전체 뮤테이션 테스트 스위트를 실행하지 않는다. 엔지니어링 팀이 뮤테이션 테스트를 CI에 통합하면서도 빌드 파이프라인을 망가뜨리지 않는 실제 방법을 소개한다.

뮤테이션 테스트 스위트가 4시간이나 걸린다면, 축하한다. 모두가 이미 의심하던 사실을 증명한 셈이다. 당신의 테스트에는 구멍이 있다. 매 푸시마다 CI에서 이걸 돌릴 생각은 하지 마라. 그런 팀은 없다. 문제는 한 커밋당 4시간을 감당할 수 있느냐가 아니다. 테스트는 통과하는데…

AI Safety Stack: types, contracts, property tests, mutation gates

AI-generated code를 production에서 버티게 하려면 code review만으로는 부족합니다. type constraints부터 mutation testing, runtime containment까지 layered safety stack이 필요합니다.

AI-generated code의 가장 위험한 점은 항상 틀리다는 데 있지 않습니다. 가장 위험한 점은 너무 자주, merge해도 될 만큼 그럴듯해 보인다는 데 있습니다. 바로 그 점이 리스크입니다. 명백히 깨진 code는 잡힙니다. 하지만 그럴듯해 보이고, 몇 개의…

훌륭한 엔지니어링 아이디어가 AI가 경제성을 만들기 전까지 틈새에 머문 이유

Design by contract, property-based testing, mutation testing, model checking은 나쁜 아이디어가 아니었습니다. 지속적으로 운영하기에 필요한 전문성이 너무 무거웠을 뿐입니다. AI가 그 방정식을 바꿉니다.

소프트웨어 엔지니어링에는 읽는 순간 바로 맞는 말처럼 느껴지는 아이디어가 많습니다. 당연히 contracts는 function이 무엇을 받아들이고 무엇을 반환해야 하는지 정의해야 합니다. 당연히 tests는 몇 개의 예제만 보는 대신 properties를 검증해야 합니다. 당연히 팀은…