https://loveAlakazam.github.io/blog/tags/%ED%95%AD%ED%95%B499/ Recent content in 항해99 on EK Dev Blog Hugo -- 0.125.7 en-us Sat, 05 Apr 2025 00:00:00 +0000 https://loveAlakazam.github.io/blog/docs/hh-08-week02-remind/ Sat, 05 Apr 2025 00:00:00 +0000 https://loveAlakazam.github.io/blog/docs/hh-08-week02-remind/ 멘토링하면서 깨달은 점 객체에게 책임을 부여시켜서 분리를 한다면 TDD 도 가능합니다. 우리는 그동안 코딩을하면서 API를 설계하고 개발했다. 코딩으로 설계를 할 수 있다 하지만 견고하거나 명확하지 않을 수 있습니다. 명확한 설계가 뒷받침된다면 코딩은 단순히 명확한 설계를 구체화하는 수단이 될 수 있습니다. 과제 발제시간에 발제 코치인 허재님이 말씀하신 부분이 기억이 남습니다. 설계가 명확하면, “코드를 치는 행위” 는 목표를 달성하는 “수단” 이 된다. 설계가 명확하지 않으면, “코드를 치는 행위” 는 불필요한 “노동” 이 된다. https://loveAlakazam.github.io/blog/docs/hh-08-week01-remind/ Sat, 29 Mar 2025 00:00:00 +0000 https://loveAlakazam.github.io/blog/docs/hh-08-week01-remind/ 멘토링하면서 깨달은 점 통합테스트/유닛테스트 의 범위는 정해져있지 않다. 통합테스트에 대한 최소 기준은 내가 호출할 친구가 통합테스트로 검증되어있는지 확인을 합니다. 단위함수가 아닌 2개이상의 함수나 외부의존성이 있는지 e2e 관점으로도 통합테스트를 할 수 있다. 비개발자 를 대상으로 내부동작보다는 호출했을때 실질적은 결과를 보여주는 테스트도 괜찮은 편. 가까운 대상을 테스트하는게 좋다 DTO입장에서는 서비스 메서드함수 한개가 통합테스트가 될 수도 있다. 단위테스트는 테스트 대상외의것들을 (서비스의 의존성을 비롯한 테스트 대상에는 해당되지않지만 서비스에 연결되어있는 대상들을) Mocking 을 해야한다. 객체에게 책임을 부여하면 불필요한 코드를 제외할 수 있다.