Development

"이 PR 리뷰할 수 있는 사람이 있을까요" — 거대 PR이 만드는 조용한 재앙 우리 프론트엔드 팀이 처음으로 컴포넌트 라이브러리 전면 교체를 결정했을 때, 첫 번째 반응은 의외로 낙관적이었습니다. "모달만 먼저 바꾸고, 그 다음에 폼, 그 다음에 테이블 순서로 가면 되지 않을까?" 하는 식이었습니다.

유닛 테스트가 "통과"해도 디자인은 무너진다 우리 프론트엔드 개발자들은 테스트 커버리지가 80%를 넘어도 프로덕션 배포 다음 날 디자이너에게 "헤더 폰트가 바뀌었어요"라는 메시지를 받는 경험을 한 번쯤 합니다. Button 컴포넌트의 로직은 완벽하게 동작하는데, CSS 변수 하나가 바뀌면서 브랜드 컬러가

유닛 테스트만으로는 사용자의 불만을 막을 수 없다 우리 프론트엔드 개발자들은 한 번쯤 이런 경험을 합니다. 개별 함수의 유닛 테스트는 모두 통과했는데, 정작 사용자가 폼을 제출하면 로딩 스피너가 사라지지 않거나, 에러 메시지가 엉뚱한 위치에 뜨는 현상입니다. 이 글은 Vitest와 MSW v2, Reac

프론트엔드 개발 환경에서 Kent Beck의 TDD와 Tidy First 완벽 적용 가이드 소프트웨어 개발 분야의 살아있는 전설, 켄트 벡(Kent Beck)이 창시한 테스트 주도 개발(Test Driven Development, TDD) 은 단순한 개발 방법론을 넘어 개발자의 사고 방식을 근본적으로 바

\n\n소프트웨어 개발 방법론의 고전이자 영원한 숙제인 TDD (Test Driven Development) . "테스트를 먼저 작성하라"는 이 단순한 원칙이 왜 실무에서는 지켜지기 어려운 걸까요? 그리고 TDD를 제대로 수행했을 때 우리는 어떤 이점을 얻을 수 있을까요? 이 글에서는 켄트 벡의 철학부터