멘토링하면서 깨달은 점 객체에게 책임을 부여시켜서 분리를 한다면 TDD 도 가능합니다. 우리는 그동안 코딩을하면서 API를 설계하고 개발했다. 코딩으로 설계를 할 수 있다 하지만 견고하거나 명확하지 않을 수 있습니다. 명확한 설계가 뒷받침된다면 코딩은 단순히 명확한 설계를 구체화하는 수단이 될 수 있습니다. 과제 발제시간에 발제 코치인 허재님이 말씀하신 부분이 기억이 남습니다. 설계가 명확하면, “코드를 치는 행위” 는 목표를 달성하는 “수단” 이 된다. 설계가 명확하지 않으면, “코드를 치는 행위” 는 불필요한 “노동” 이 된다....
멘토링하면서 깨달은 점 통합테스트/유닛테스트 의 범위는 정해져있지 않다. 통합테스트에 대한 최소 기준은 내가 호출할 친구가 통합테스트로 검증되어있는지 확인을 합니다. 단위함수가 아닌 2개이상의 함수나 외부의존성이 있는지 e2e 관점으로도 통합테스트를 할 수 있다. 비개발자 를 대상으로 내부동작보다는 호출했을때 실질적은 결과를 보여주는 테스트도 괜찮은 편. 가까운 대상을 테스트하는게 좋다 DTO입장에서는 서비스 메서드함수 한개가 통합테스트가 될 수도 있다. 단위테스트는 테스트 대상외의것들을 (서비스의 의존성을 비롯한 테스트 대상에는 해당되지않지만 서비스에 연결되어있는 대상들을) Mocking 을 해야한다. 객체에게 책임을 부여하면 불필요한 코드를 제외할 수 있다....
지금까지의 회고 현재는 스스로 찾아야되고 병행을 해야했지만, 나를 더 디벨롭하고 싶습니다. 시간관리의 중요성을 느꼈고, 늦게 출발하고 남들보다 뒤처지기도 했습니다. 이제는 더이상 뒤쳐지고 싶지 않습니다. 느리다는 이유로 많이 회피해왔던 것도 있고 자신감이 없어지기도 했습니다. 남과 비교하면서 나를 깎아 내렸으니까요. 그치만 계속 비교로 나를 채찍질하기보다는 내가 느린걸 인정하고 나의 페이스대로 묵묵히 꾸준히 문제를 하나씩 해결해나가고 싶습니다. 항해플러스에 참여한 계기 단순 CRUD API 설계 및 개발이 아닌 한단계 더 나아가고 싶습니다. 실무진과 선배개발자들은 어떤 코드/설계/철학을 원하는지 궁금합니다....