[회고록] 깨진 유리창 이론

---

🐶 Pet DAM (반려동물 다이어리)

2023년 7월 10일 (월) ~ 2023년 7월 19 (수) 기간 동안엔 펫담이란 프로젝트에 시간을 쏟았다.

그동안 TDD를 공부해오면서 실전 프로젝트를 통해 경험까지 해보고 싶다고 생각하던 와중에 이번 A to Z 프로젝트 과제가 시작되었다. 이번 프로젝트를 통해서 TDD를 실전 프로젝트에 적용해보면서 개발해보려고 한다. 

---

🩹 깨진 유리창 이론

깨진 유리창 하나를 방치하면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론

이 기간에는 회원가입과 로그인 요구사항에 초점을 맞춰서 TDD 방식을 토대로 완성하는 것이 목적이였다. 먼저 회원가입 요구사항에 맞춰 테스트를 시작하는 부분은 순조로웠다.

 

예를 들어, "회원의 이메일과 핸드폰 번호는 중복될 수 없다." 등과 같이 테스트 코드 짜는 부분이 쉬웠기 때문에, 요구사항과 테스트 코드에 맞게 엔티티도 설계가 됐고 무난하게 흘러갔다.

 

하지만 로그인 요구사항을 위해 테스트를 만들기 시작하자마자 나의 TDD는 무너졌다. 로그인 요구사항을 위해 "Spring Security + JWT"를 학습하고 "RefeshToken" 저장소로 'Redis'를 사용하게 되면서 실패한 테스트를 성공시키기 위해 많은 노력이 들어갔고 점점 테스트 코드에서 멀어졌다. 그렇게 하나가 무너지자 무너진 테스트 코드 중심으로 테스트 코드가 무너진 것이다.

 

📌 실전 프로젝트로 공부를 하지 않았다면 절대 경험해보지 못했을 것이다. 백문이 불여일견 ❗️

---

📝 피드백 - TDD와 Spring Security + JWT

위와 같은 악순환이 만들어지지 않으려면 어떻게 해야할까..❓

테스트 코드 자체의 유지보수성이 좋아야 할 것이다. 테스트 코드를 유지보수하기 좋아야 지속적으로 테스트를 작성하게 되고 결과적으로 소프트웨어의 품질이 떨어지는 것도 막을 수 있을 것이다. 한두 개의 실패한 테스트를 방치하기 시작하면 점점 실패하는 테스트가 증가해서 나중에는 테스트를 고칠 수 없을 지경에 이르게 될 것이다.

 

나는 이 실전 프로젝트에서 로그인 요구사항에 대한 테스트를 하나씩.. 하나씩.. 포기하면서 확실히 이 부분을 몸소 느꼈다. 애초에 실패하는 테스트가 많아져 테스트 자체를 실행하지 않게 되고 소프트웨어 품질 저하까지 연결되는 것을 방지하기 위해 깨진 테스트가 발견될 때, 즉시 수정해서 확산되지 않게 하자.

 

그리고 이런 부분에서 "내가 왜 실패 테스트를 수정하는데 많은 노력을 했을까?" 란 생각을 해봤는데, 이는 Spring Security에 대한 지식이 많이 부족해서 였다고 생각한다. Filter의 흐름을 완벽하게 인지하고 어떤 부분에서 커스텀을 진행하는 것이 좋은 지, Spring Security와 JWT를 함께 썼는데, 왜 같이 썼는지, 둘의 역할은 무엇인 지 등처럼 완벽하게 공부했다면, 테스트 코드를 짜는데도 훨씬 수월했을 것이다.

 

📌 어떤 기술이든 사용하기 위해선 학습을 제대로 하고 들어가자.