한 주를 돌아보며 회고를 작성합니다
TDD
1주차는 TDD로 point 이용 / 충전 관련 애플리케이션을 만드는 과제를 진행했다.
평소 개발 방식이 기능 구현 → 테스트 작성 순이었는데, 역순으로 테스트 코드 작성을 먼저 하려니 어색하고 생각해야 할 부분이 많았다.
어떤 기능을 구현해야 하는지 요구사항을 정확히 파악해야 테스트 코드를 작성할 수 있는데, 테스트 코드를 먼저 작성하면서 하나의 시나리오를 구성한다고 생각하면 편했다.
예를 들어 포인트를 충전하는 기능을 구현한다면, 테스트 코드를 아래의 흐름으로 먼저 작성할 수 있다.
- 포인트를 충전할 사용자의 정보를 준비한다.
- 해당 정보의 사용자에 포인트를 충전하는 메서드를 호출한다.
- 메서드의 결괏값이 내가 예상한 결괏값과 일치한지 검증한다.
테스트 코드를 작성할 때, 검증하려는 대상의 관심사만 검증해야지 이 대상이 의존하고 있는 다른 컴포넌트에 대해서는 신경 쓰지 않아야 한다.
즉, 의존하고 있는 컴포넌트가 변경이 되어도 기능 자체는 변경되지 않고 의도한 대로 동작해야 한다.
예를 들어, 전기밥솥에게 밥을 짓는 명령을 내렸을 때, 밥솥이 전기밥솥에서 보온 밥솥 또는 압력 밥솥으로 변경이 되어도 똑같이 밥이 지어져야 한다.
비유가 맞나..? 암튼 중요한 건 밥솥의 종류가 아닌 밥솥이 밥을 지을 수 있는지에 대한 검증(행위 자체에 대한 검증)이 이루어져야 한다.
그래서 특정 서비스의 Unit Test 코드를 작성할 때, 이 서비스가 의존하고 있는 Repository와의 의존성을 Stub이나 Mock을 통해 제거해야 한다.
Mock? Stub?
이번에 Stub이라는 개념을 알게 되었는데, 평소 테스트 할 때는 Mock을 통해 테스트를 작성했었는데 이번에는 Stub 방법을 적용해 테스트 코드를 작성해 봤다.
개인적으로 이번에 Stub을 이용해 테스트를 진행해 보고 느낀 점은 테스트해야 할 컴포넌트가 많아지고 해당 컴포넌트가 의존하는 구현체들이 많아지면 그만큼 stubbing 해야 할 것들이 많아져 stub 클래스를 만드는 것도 비용이라고 생각이 들어 stub 보단 mock을 사용하는 게 더 편하다고 느꼈다. (아직 stub에 익숙하지 않아서 그럴숟..)
반대로 Mock을 사용한다면 테스트 대상의 동작 방식을 알아야 mocking을 할 수 있다는 생각을 했는데, 이러한 생각이 아직 TDD로 개발하는 것을 힘들게 하는 것 같다.
아무튼 Mock을 선호하시는 코치님들도 계시고, Stub을 선호하시는 코치님들도 계시는 것처럼 Mock과 Stub 중 어떤 방법을 사용하여 테스트할지는 취향차이인 것 같다.
1주 차 회고가 늦어 벌써 2주 차도 마무리되어가는데, 이 시점에서 느끼는 것은 확실히 모르는 것을 멘토링 시간에 질문해야 많은 것을 얻어 갈 수 있다는 것을 느꼈고, 이전에는 모르는것을 모른다고 말할 수 있는 용기가 부족했는데 이번에는 최대한 많은 것을 얻어갈 수 있도록 모르는 건 짚고 넘어가자.
1주 차 끄읕..
'성장이야기 > 주간회고' 카테고리의 다른 글
| 2024년 4월 1주차 주간회고 (0) | 2024.04.09 |
|---|---|
| 2024년 3월 4주차 주간회고 (4) | 2024.03.30 |
| 2023년 6월 2주차 주간회고 (0) | 2023.06.11 |
| 2023년 6월 1주차 주간회고 (0) | 2023.06.04 |
| 2023년 5월 4주차 주간회고 (0) | 2023.05.28 |