2단계 - 중복 제거와 구조화

[jheee0130]

안녕하세요. 이단계도 재밌게 진행했고 이번에는 궁금증을 많이 들고 찾아왔습니다! ㅎㅎ

1. 인수 테스트의 장점은 이해했는데, 보통 간단한 리팩토링뿐만 아니라 완전히 새로운 버전으로 갈아엎는 경우도 있지 않나요?
   추가 요구사항이 크게 늘어나고 설계 변화가 많아 흔히 말하는 ‘차세대 프로젝트’로 진행되는 상황에서는 기존과 DB 설계 자체가 달라질 텐데, 이 경우에도 인수 테스트가 의미를 가질 수 있는지 궁금합니다.
   이런 상황에서 변경된 DB 구조에 맞춰 기능을 옮기고, 그 결과를 인수 테스트로 검증하는 것이 가능한지도 알고 싶습니다.

2. AI를 활용해서 전체적인 시나리오를 작성했는데, 일반적으로는 있어야 하지만 아직 구현되지 않은 기능을 가정하고 시나리오까지 생성해줘서 일부 테스트는 실패하더라구요.
   이때 당장은 구현이 불가능하더라도 장기적으로 개선할 방향을 명확히 하기 위해 시나리오를 미리 작성해 두는 것이 맞는지, 아니면 현재 구현되어 있는 기능 범위 내에서만 테스트를 작성하는 것이 더 적절한지 기준이 궁금합니다.
   참고로 현재는 즉시 실패하는 테스트들은 future 성격의 시나리오로 분리해 남겨둔 상태인데 이런 접근이 적절한지도 함께 의견을 듣고 싶습니다.

3. 초기 데이터 생성 방식에 대한 고민입니다.
   Repository를 직접 사용해 데이터를 생성해도 되는지, 아니면 test용 API를 만들어서 API 기반으로 테스트하는 것이 더 나은지 판단이 어렵습니다.
   어드민 프로젝트 특성상 모든 API가 존재하지도 않고, DatabaseHelper 같은 유틸을 만들어서 사용할 경우 테스트 코드가 비즈니스 로직과 강하게 결합되어 실제 로직 변경 시 테스트도 함께 수정해야 하는 단점이 있는 것 같습니다.
   이런 상황에서는 어떤 접근이 가장 적절한지 의견을 듣고 싶습니다.

4. 마지막으로, 성현님 팀내에서는 바이브 코딩을 할 때 claude.md 같은 컨벤션 / 가이드 룰 파일을 팀 공용으로 Git 저장소에 함께 관리하는지,
   아니면 개인별로 관리하는 편인지도 궁금합니다!

[boorownie]

2단계 구현하시느라 고생 많으셨습니다!
구조화도 잘 해주시고 재사용도 잘 해주셨어요!

지금 작성된 인수 테스트의 수가 적어서 그 효과를 체감하기 어려울 수 있는데요
요구사항 첫 줄의 내용에 맞춰 다른 모든 기능들에 대해서도 인수 테스트를 구축해보시는걸 제안드립니다!

질문주신 부분에 있어서는 관련 코드에 코멘트로 남겨두었습니다!

폭 넓은 경험을 위해 파악한 모든 기능에 대한 인수 테스트를 구축해보는 것을 추천합니다.

[boorownie]

인수 테스트의 장점은 이해했는데, 보통 간단한 리팩토링뿐만 아니라 완전히 새로운 버전으로 갈아엎는 경우도 있지 않나요?
추가 요구사항이 크게 늘어나고 설계 변화가 많아 흔히 말하는 ‘차세대 프로젝트’로 진행되는 상황에서는 기존과 DB 설계 자체가 달라질 텐데, 이 경우에도 인수 테스트가 의미를 가질 수 있는지 궁금합니다.
이런 상황에서 변경된 DB 구조에 맞춰 기능을 옮기고, 그 결과를 인수 테스트로 검증하는 것이 가능한지도 알고 싶습니다.

인수 테스트의 목적이 중요할 것 같습니다. 이번 과정에서는 레거시 코드를 기반으로 리팩터링을 하거나 신규 기능을 구현하는 상황에서 기존 기능의 영향을 최소화하도록 하는 안전장치의 역할을 하면서 새로운 기능의 대한 등대 역할을 하는 것을 기대할 수 있습니다.

이 경우 기존 기능에 대한 인수 테스트를 구성하는 것을 시작으로, 새로운 기능에 대한 인수 테스트를 작성한 뒤 기존 기능이 깨지지 않는 선에서 새로운 기능을 구현합니다. 이후 새로운 기능 구현이 끝나면 기존 테스트를 제거하는 식으로 사용할 수 있습니다!

[boorownie]

마지막으로, 성현님 팀내에서는 바이브 코딩을 할 때 claude.md 같은 컨벤션 / 가이드 룰 파일을 팀 공용으로 Git 저장소에 함께 관리하는지, 아니면 개인별로 관리하는 편인지도 궁금합니다!

우선 공용으로 관리하는 것을 중요하게 생각하고있는데요, 팀으로 활용하는 부분은 제가 경험이 많지 않다보니 공유할 노하우가 많지는 않습니다. 물론 처음부터 함께 관리하기보다는 처음에는 개인별로 관리하여 사용하다가 컨플릭이 나는 시점이 오면 하나씩 맞춰가는게 중요한 것 같아요.

문서의 종류와 양은 최소한으로 관리하는 원칙을 세워서 점진적으로 맞춰서 나가 문서를 구축하는게 좋을 것 같아요!

[boorownie]

초기 데이터 생성 방식에 대한 고민입니다.
Repository를 직접 사용해 데이터를 생성해도 되는지, 아니면 test용 API를 만들어서 API 기반으로 테스트하는 것이 더 나은지 판단이 어렵습니다.
어드민 프로젝트 특성상 모든 API가 존재하지도 않고, DatabaseHelper 같은 유틸을 만들어서 사용할 경우 테스트 코드가 비즈니스 로직과 강하게 결합되어 실제 로직 변경 시 테스트도 함께 수정해야 하는 단점이 있는 것 같습니다.

프로덕션 코드 변경의 영향을 최소한으로 받도록 api를 기준으로 사용하되, 이게 어려울 경우 repository를 활용하여 데이터 설정하는 것을 추천드리고 있습니다. repository도 사용하기 어려울 경우 디비에 접근해서 데이터를 설정하는 방법을 제안드립니다. 물론 이는 뒤로갈 수록 깨지기 쉬운 테스트 코드에 가깝지만 깨지기 쉽다고해서 테스트를 구현하지 않는 것 보다는 좋고 이런 방식들을 연습해보는 차원에서 말씀드렸습니다.

[boorownie]

AI를 활용해서 전체적인 시나리오를 작성했는데, 일반적으로는 있어야 하지만 아직 구현되지 않은 기능을 가정하고 시나리오까지 생성해줘서 일부 테스트는 실패하더라구요.
이때 당장은 구현이 불가능하더라도 장기적으로 개선할 방향을 명확히 하기 위해 시나리오를 미리 작성해 두는 것이 맞는지, 아니면 현재 구현되어 있는 기능 범위 내에서만 테스트를 작성하는 것이 더 적절한지 기준이 궁금합니다.
참고로 현재는 즉시 실패하는 테스트들은 future 성격의 시나리오로 분리해 남겨둔 상태인데 이런 접근이 적절한지도 함께 의견을 듣고 싶습니다.

우선 AI 도구의 도움을 받아 시나리오를 구성하다보면 기존 기능에서 놓치고 있던 부분까지 파악할 수 있는데요, 이 경우 실패하는 시나리오는 미리 작성해두기 보다는 이슈 티켓에 기록해두어 훗날 구현할 때 사용하여 구현하는 방법을 추천드립니다.