제 컴에서는 되는데요?(It works on my computer)

지난 [SI 프로젝트 TDD 실천기 1탄]에 이어서 실천기 2탄 써보려고 합니다. 다만 이번에는 TDD가 중심이 되기보다는 TDD를 통한 개발 스타일이 SI에서 어떻게 활용되면 좋을지, 어떤 부분에서는 활용이 어려운지를 중심으로 말 그대로 느낀 점을 전달하고자 합니다. (사실 통합 테스트부터는 테스트 코드가 중심이 되기보다는 트러블슈팅 및 개선사항 반영에 정신없어 테스트 코드 관리에 실패했습니다😭 ) 통합 테스트 TDD의 필요성이 가장 높아지는 시기입니다. 이번 프로젝트는 특히 로그인 및 인증에서 버그가 많았습니다. 공인인증서, 휴대폰 인증, 생체인증, 카카오페이 인증 등 4개의 방법과 PC, Mobile에 따라 8개로 구분되며, 인증방법 역시 동일한 수만큼 가능했습니다. 또한 고객의 타입에 따라 비즈니..

테스트의 중요성이 대두되고 있습니다. 이미 기본적인 개발룰로 적용되어 강제적으로 작성해야하는 회사도 있고, 아직까지 테스트는 거추장스럽고 불필요한 시간을 소모시키는 천덕꾸러기로 생각하는 회사도 있습니다. 오늘날은 바야흐로 테스트 코드의 과도기라고 할 수 있다고 생각합니다. 이런 시대에 맞춰 테스트코드를 작성하기 시작하는 분들을 위해, 테스트 코드를 작성하기에 어떤 것들이 방해하는지 경험적이고 주관적인 생각들을 꺼내보겠습니다. 1. TDD(Test-Driven Development) '응? 테스트 열풍의 중심인 TDD가 오히려 테스트를 시작하는데 방해한다고?' 네 그렇습니다. TDD는 생각보다 극단적으로 치우쳐있습니다. 어떤 개발을 하든 테스트 코드를 작성해두고, 이를 하나씩 통과시켜가는 과정으로 개발을 ..

저는 주로 보험사 사이버창구 업무에 관해 SI프로젝트를 하고 있습니다. 운 좋게 이번 프로젝트에서는 킥오프부터 투입하게 되어 프레임워크 설정에 대해 적극적으로 참여할 수 있었습니다. 그래서 기존 소스분석 과정에서 불필요한 부분은 과감히 줄이고, 새로운 프로젝트에 필요한 라이브러리를 자유롭게 추가하기도 했습니다. 이런 상황에서 몇 가지 키워드를 중심으로 SI 프로젝트에서 TDD를 실천한 후기를 써보겠습니다. 오프라인 프로젝트의 문제점 보험사를 비롯하여 금융 프로젝트는 대부분 인터넷을 사용할 수 없습니다. 이런 제약 속에서 먼저 떠오르는 생각은 단연 구글링입니다. 구글링 없는 개발은 상상하기도 힘든 오늘날의 개발실정에 통감하게 됩니다. 하지만 시간이 지나면 진짜 문제는 프로젝트의 의존성 관리입니다. 의외로 ..