최영선의 블로그

테스트를 많이 쓰는 팀이 항상 잘 운영되는 것은 아닙니다. 모든 함수에 단위 테스트를 붙이고, 모든 화면에 E2E 테스트를 추가하면 겉보기에는 촘촘해 보일 수 있습니다. 그런데 CI가 30분씩 걸리고, 플래키 테스트가 늘고, PR 속도가 급격히 떨어지면 그 체계는 버그보다 느린 개발 속도를 더 많이 만들 수 있습니다.그래서 마지막에는 수량보다 배치를 봐야 합니다. 어떤 계층에 얼마를 투자할지, 어디를 두껍게 보호할지, 무엇을 문서가 아니라 팀 습관으로 남길지를 결정하는 일이 전략입니다.이 글은 Testing 101 시리즈의 마지막 글입니다. 여기서는 테스트 피라미드의 분포, 계층별 투자 대비 효과, 계약 테스트와 팀 운영 습관, 그리고 전략을 살아 있는 규칙으로 유지하는 방법을 정리하겠습니다.Testin..

노트북에서는 통과했는데 동료 환경이나 머지 뒤 파이프라인에서는 깨지는 일은 흔합니다. 파이썬 버전이 다르거나, 의존 패키지 캐시 상태가 다르거나, 로컬에만 있는 파일 하나가 원인일 수도 있습니다. 로컬 통과만으로는 팀 전체 기준을 만들기 어렵습니다.그래서 테스트는 개인 습관에만 맡기지 않고 공통 환경에서 자동으로 돌려야 합니다. 그 역할을 맡는 것이 CI입니다.이 글은 Testing 101 시리즈의 아홉 번째 글입니다. 여기서는 CI의 목적, GitHub Actions 워크플로의 기본 구조, 매트릭스와 캐시로 속도를 줄이는 방법, 그리고 테스트 결과를 팀 공통 신호로 운영하는 감각을 정리하겠습니다.Testing 101 9장 흐름 개요CI 없는 테스트는 개발자의 책임이지만, CI가 있는 테스트는 팀의 안전..

버그를 한 번 고친 뒤에도 몇 달 뒤 같은 문제가 다시 돌아오는 경우가 있습니다. 코드는 바뀌고 사람도 바뀌기 때문입니다. 누군가 예전 맥락을 모른 채 같은 경로를 다시 깨뜨리면, 팀은 이미 고친 문제를 다시 조사하고 다시 수정하게 됩니다.소프트웨어는 스스로 기억하지 않습니다. 그래서 버그 수정을 코드로 얼려 두는 장치가 필요합니다. 그 역할을 하는 것이 회귀 테스트입니다.이 글은 Testing 101 시리즈의 여덟 번째 글입니다. 여기서는 회귀 테스트의 의미, 버그를 테스트로 재현하고 수정으로 연결하는 흐름, 그리고 회귀 테스트를 어디 계층에 두는 편이 좋은지 정리하겠습니다.Testing 101 8장 흐름 개요회귀 테스트는 과거의 고통을 재무보험입니다. 한 번 깨진 부분이 다시 깨지지 않도록 합니다.먼..

테스트를 어느 정도 썼는지 물으면 많은 팀이 숫자부터 말합니다. 80퍼센트인지, 90퍼센트인지, 아니면 100퍼센트를 목표로 하는지 같은 이야기입니다. 그런데 숫자만 보면 금방 착시가 생깁니다. 코드가 실행되었다는 사실과, 올바르게 검증되었다는 사실은 다르기 때문입니다.커버리지는 유용합니다. 다만 목표가 아니라 진단 도구로 다룰 때만 유용합니다. 숫자를 올리기 위해 의미 없는 테스트를 추가하는 순간 지표는 남고 신뢰는 빠집니다.이 글은 Testing 101 시리즈의 일곱 번째 글입니다. 여기서는 라인, 브랜치, 함수 커버리지의 차이, pytest-cov로 측정하는 기본 흐름, 그리고 100퍼센트 숫자에 집착할 때 생기는 문제를 정리하겠습니다.Testing 101 7장 흐름 개요커버리지는 지표일 뿐 목표가..

테스트 더블을 배운 뒤에도 Mock과 Stub은 자주 뒤섞입니다. 둘 다 가짜 객체처럼 보이기 때문입니다. 그런데 목적은 꽤 다릅니다. 이 차이를 놓치면 결과를 검증해야 할 테스트를 호출 검증으로 가득 채우거나, 반대로 상호작용이 핵심인 테스트를 너무 느슨하게 만들게 됩니다.좋은 테스트는 실패했을 때 무엇이 깨졌는지 한 줄로 말해 줍니다. Mock과 Stub을 구분하는 일은 그 한 줄을 선명하게 만드는 작업입니다.이 글은 Testing 101 시리즈의 여섯 번째 글입니다. 여기서는 unittest.mock 예제를 바탕으로 Mock과 Stub의 목적 차이, 상태 검증과 상호작용 검증의 차이, 그리고 과한 Mock 사용이 보내는 설계 신호를 정리하겠습니다.Testing 101 6장 흐름 개요Stub은 응답을..

단위 테스트를 쓰다 보면 곧 외부 의존과 마주칩니다. 메일 전송, 결제 API, 현재 시간, 데이터베이스처럼 실제로 호출하면 느리거나 비싸거나 불안정한 대상들입니다. 이런 의존을 매번 진짜로 호출하면 테스트가 느려지고, 실패 원인도 코드가 아니라 외부 환경으로 번집니다.그래서 테스트에서는 실제 의존 대신 대역을 씁니다. 다만 대역도 하나로 뭉뚱그리면 금방 헷갈립니다. 반환값만 흉내 내는 경우와 호출 자체를 기록하는 경우는 목적이 다르기 때문입니다.이 글은 Testing 101 시리즈의 다섯 번째 글입니다. 여기서는 테스트 더블의 다섯 종류를 구분하고, 언제 무엇을 써야 하는지, 그리고 왜 과한 목 사용이 문제를 만드는지 정리하겠습니다.Testing 101 5장 흐름 개요테스트 더블은 외부 의존을 제어함으..

로그인 화면이 잘 보이고, 버튼도 눌리고, API도 정상이라고 각자 확인했는데 실제 사용자는 로그인조차 못 하는 상황이 생길 수 있습니다. 화면과 백엔드, 데이터베이스가 각각 정상이어도 끝에서 끝까지 이어지는 사용자 흐름은 다른 문제를 드러내기 때문입니다.E2E 테스트는 그 흐름을 사용자의 시선에서 다시 확인합니다. 비용이 가장 큰 대신, 실제 사고와 가장 가까운 신호를 줍니다.이 글은 Testing 101 시리즈의 네 번째 글입니다. 여기서는 E2E 테스트의 역할, Playwright로 첫 시나리오를 만드는 방법, 그리고 플래키(flaky)한 테스트를 줄이는 운영 원칙을 정리하겠습니다.Testing 101 4장 흐름 개요E2E 테스트는 현실적인 지만 느린 신호입니다. 따라서 시간 효율을 위해 주요 사용..

단위 테스트가 모두 초록색인데 실제 환경에서는 500 오류가 나는 장면은 낯설지 않습니다. 함수 하나씩 떼어 놓고 보면 맞았지만, HTTP 라우팅과 서비스 계층, 저장소, 데이터베이스가 이어지는 순간 계약이 어긋나는 경우가 많기 때문입니다.실무 버그는 모듈 내부보다 경계에서 자주 나옵니다. 스키마가 달라졌거나, 요청 형식이 달라졌거나, 권한 체크가 예상과 다르게 엮이는 식입니다. 통합 테스트는 바로 그 경계를 보는 테스트입니다.이 글은 Testing 101 시리즈의 세 번째 글입니다. 여기서는 통합 테스트가 단위 테스트와 어떻게 다른지, 실제 DB와 HTTP 계층을 왜 붙여 보는지, 그리고 느린 테스트를 어떻게 다루는지 정리하겠습니다.Testing 101 3장 흐름 개요통합 테스트는 부품 조립 상태의 계..

테스트를 처음 배우면 가장 먼저 드는 질문이 있습니다. 어디까지를 하나의 테스트 단위로 봐야 할까요? 함수 하나일 수도 있고, 메서드 하나일 수도 있고, 클래스의 특정 동작 하나일 수도 있습니다. 범위를 너무 넓게 잡으면 원인을 찾기 어려워지고, 너무 모호하게 잡으면 테스트가 금방 무거워집니다.그래서 단위 테스트는 크기를 줄이는 연습이기도 합니다. 외부 의존을 걷어 내고, 작은 동작 하나를 빠르게 확인하는 방식으로 신뢰를 쌓습니다.이 글은 Testing 101 시리즈의 두 번째 글입니다. 여기서는 단위 테스트의 범위, AAA 패턴, pytest의 기본 작성법, 그리고 좋은 단위 테스트가 갖춰야 할 조건을 정리하겠습니다.Testing 101 2장 흐름 개요단위 테스트는 한 가지 동작만 검증하고, 같은 동작..

처음 테스트를 배울 때는 코드보다 절차부터 떠올리기 쉽습니다. 서버를 띄우고, 브라우저를 열고, 회원가입 버튼을 눌러 보고, 로그인이 되는지 확인하는 식입니다. 이 방식은 처음 한두 번은 통합니다. 그런데 기능이 늘고 사람이 늘면 곧 같은 질문이 따라옵니다. 어제 확인한 기능을 오늘도 다시 손으로 눌러 봐야 할까요?변경이 잦은 코드베이스에서는 수작업 확인만으로 품질을 지키기 어렵습니다. 확인 범위가 넓어질수록 빠뜨리는 항목이 생기고, 그 공백은 배포 뒤에 사고로 돌아옵니다.이 글은 Testing 101 시리즈의 첫 번째 글입니다. 여기서는 테스트가 무엇인지, 자동 테스트가 왜 필요한지, 그리고 뒤이어 나올 단위 테스트·통합 테스트·E2E 테스트가 어떤 자리에 놓이는지부터 정리하겠습니다.Testing 10..