인프런 워밍업 클럽 2기 발자국 3주차

1. 한 주의 정리

이번 주차부터는 테스트 코드 학습이 시작됐다.

테스트 코드는 뭔가 짜야지 짜야지 하면서, 처음 하려고 하면 뜬 구름 같은..?

마치 헬스장을 PT 없이 처음 가는 기분일까..? 아무래도 유튜브나 이런걸 보고 할 순 있지만 뭔가

처음가면 런닝머신만 뛰고 오기 부지기수이다.

나에게 테스트 코드는 그런 느낌이었다.

혼자서 짜면 굉장히 얇은 층만 건들이다가 마는 것 같은..? 3주차에서는 일단 내가 건들이던 층까지라

크게 다를 것은 없었지만 그럼에도 많은 것들을 배웠다.

✅ 섹션 2. 테스트는 왜 필요할까?

테스트의 필요성에 대해 먼저 간략히 알려주는 섹션이다.

여기서 말씀 주신 것들의 대부분이 공부를 하거나 일을 할 때 테스트 코드가 없는 경우에 느낀 불편함들이 있었다.

이 섹션에서는 그러한 불편한 부분들 그리고 테스트 코드 자체로 발생할 수 있는 불편함들에 대해 정리 해주고 있다.

✅ 섹션 3. 단위 테스트

가장 쉽게 접근할 수 있고 또 빠르게 테스트를 할 수 있는 단위 테스트에 대해 학습했다.

단위 테스트를 작성하는 기법이나 프레임워크 등 그리고 어떤 것들을 테스트해야 하는 지 생각하는 방식 등을 알 수 있어 조금은 테스트에 있어 어색한 나에게 좋은 섹션이었다.

특히 테스트하기 어려운 것과 쉬운 것을 구분하고

테스트하기 쉬운 구조로 변경하는 방법이 꽤 도움이 되었다.

반면에 테스트하기 쉽게 프로덕트를 변경하는 것이 옳은 것인가? 에 대해 한번 고민하게 되었다

✅ 섹션 4. Test Driven Development

한 동안 엄청나게 많은 사람들을 괴롭힌 TDD이다

강의에서 간략한 요약으론

프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론

RED : 실패하는 테스트 작성

GREEN : (빠른 시간 내에) 테스트 통과 최소한의 코딩

REFACTOR : 구현 코드 개선 테스트 통과 유지

위와 같이 안내해준다. 이 장에 대해선 좀 모호하다. 나는 TDD를 옹호하고 긍정적인 쪽은 아니다.

그러나 테스트 코드는 중요하다고 생각한다.

프로덕트를 먼저 짜든 테스트를 먼저 짜든 중요한 것은 그 본질이라 생각하며

나는 그 부분이 요구사항을 만족하며 최대한 꼼꼼한 기능 구현이라고 생각한다.

✅ 섹션 5. 테스트는 [ ] 다

괄호 안의 내용을 말하는 것이 강의의 스포일까..?

두루뭉술하게 말하자면

테스트 자체도 보기 쉽게 작성을 해야한다는 강의 내용이었다.

@DisplayName을 명확히 작성한다든지 gwt나 gw&t 방식으로 구분지어 테스트를 작성하여 보기 쉽게 만들어 주는게 좋지 않을까요? 하는 관점이었다.

✅ 섹션 6. Spring & JPA 기반 테스트

쓸 건 많은데 쓰기엔 좀.. 강의 내용을 너무 적나라하게 내보낼까봐 조심스럽다.

그리고 나 또한 강의의 내용을 그대로 옮기는 회고를 선호하지 않기에..

이 장에서는 Layerd Architecture에서 많이 활용되는 방식의 테스트 구조를 설명하고

아랫단에서부터 올라가고 있다. 우선 이번 주차에선

[6-2] Business Layer까지라 나눠서 작성하기도 애매하고..

일단은 이 강의의 가장 핵심 부분이지 않나 싶다 섹션 6과 7은

그 밖에도 테스트 상황에서 발생할 수 있는 여러 문제 상황들을 상세하게 재연해주시므로 도움이 많이 되는 장이다.

2. 미션

이번 주차에서는 테스트 코드를 작성하는 미션이 진행됐다.

코드의 양이 꽤 많으므로 github 링크를 같이 첨부하며 어떤 식으로 접근 했는 지 설명하겠다.

https://github.com/ckaanf/readable-code/tree/mission/day-12

✅ 아래부터 차근 차근

처음 테스트가 하나도 없는 코드를 받으면 숨이 턱..

왜냐하면 테스트 상황에 대한 구조부터 하나하나 쌓아 올려가야 하기 때문이다.

그나마 이 프로젝트는 Spring이 아니었기에 여러 Mock들이나 스프링 Bean에 의해 발생하는 문제는 없어서 다행이었다.

타고타고타고

나는 일단 메인 비즈니스 로직에서 메서드를 계속 타고 최하단 까지 내려 가는 것으로 먼저 테스트 코드를 작성했다.

거기서 객체 수준의 테스트가 필요하다고 생각되면 작성을 하였고 또 역으로 그 객체를 사용하는 위치로 가서 테스트 코드를 작성했다.

미션은 테스트 코드 작성

두 번째로는 테스트를 위한 프로덕트의 변경은 하지 않았다.

그저 내가 생각하기에 필요하다고 생각되는 테스트 케이스는 작성하되 그것이 통과하도록 프로덕트를 변경하진 않았다.

이번 미션은 테스트 코드 작성이지 리팩토링이나 기능의 변경이 아니라고 생각했기 때문이다.

그렇기에 실패하는 테스트도 존재하며, 그것은 의도된 것임을 밝힌다

최대한 독립적으로

마지막으로는 최대한 독립적으로 짜려고 했다.

서로의 테스트가 서로에게 영향을 주지 않도록,

그리고 프로덕트의 코드의 변경이 테스트의 영향을 주지 않도록,

또한 테스트하려고 하는 When 외에 변경을 반영하지 않도록 말이다.

🤔 내 생각을 정리하자면

테스트 코드는 분명 중요하다.

그러나 테스트 코드는 테스트 코드여야 한다.

그 책임을 넘어 프로덕트의 책임까지 침범하거나 그 이상의 권한이 주어져서는 안된다고 생각한다.

이번에 적은 양의 코드지만 테스트를 짜면서 느낀 것은 이 적은 양도 꽤 많은 테스트가 필요한데 프로덕트 코드의 테스트는 얼마나 복잡할까?

그리고 그걸 지속가능하게 관리하려면 어떻게 해야할까? 등에 대한 생각을 하게 됐다.

다음 주에는 그런 것을 바탕으로 테스트 코드를 관리하는 방법들이나

테스트 코드를 분리하는 방법에 대해 같이 공부하면서 강의를 마무리 해야겠다.