4 posts
Property-based testing의 기본값인 100개 예제는 통계 전략이 아닌 사회적 타협이다. 자신의 신뢰도 요구사항과 CI 예산에 맞는 실행 횟수를 선택하는 방법을 알아보자.
property-based test를 기본값 100개 예제로 실행하고 있다면, 양쪽 모두 최악의 상황을 겪고 있는 것이다. CI는 필요 이상으로 느리고, 여전히 중요한 버그는 놓치고 있다. 이 숫자에 마법 같은 건 없다. Hypothesis를 포함한 대부분의 라이브러리가 100을…
Example-based testing은 당신이 생각해낸 입력만 커버한다. Property-based testing은 무작위 데이터를 생성하고, invariant를 검증하며, 실패를 최소한의 counterexample로 축소한다.
당신은 함수를 작성했다. 과 로 테스트했다. 통과했다. 배포했다. 한 사용자가 한 개의 원소를 가진 slice를 넘겼다. 당신의 함수는 그것을 무시하고 지나쳤다. 이슈가 열렸다. 당신은 테스트 파일을 응시하며 이렇게 뻔한 것을 어떻게 놓쳤는지 의아해한다. 놓친 이유는…
AI-generated code를 production에서 버티게 하려면 code review만으로는 부족합니다. type constraints부터 mutation testing, runtime containment까지 layered safety stack이 필요합니다.
AI-generated code의 가장 위험한 점은 항상 틀리다는 데 있지 않습니다. 가장 위험한 점은 너무 자주, merge해도 될 만큼 그럴듯해 보인다는 데 있습니다. 바로 그 점이 리스크입니다. 명백히 깨진 code는 잡힙니다. 하지만 그럴듯해 보이고, 몇 개의…
Design by contract, property-based testing, mutation testing, model checking은 나쁜 아이디어가 아니었습니다. 지속적으로 운영하기에 필요한 전문성이 너무 무거웠을 뿐입니다. AI가 그 방정식을 바꿉니다.
소프트웨어 엔지니어링에는 읽는 순간 바로 맞는 말처럼 느껴지는 아이디어가 많습니다. 당연히 contracts는 function이 무엇을 받아들이고 무엇을 반환해야 하는지 정의해야 합니다. 당연히 tests는 몇 개의 예제만 보는 대신 properties를 검증해야 합니다. 당연히 팀은…