[인프런 워밍업 클럽 백엔드 스터디 2기] 3주차 발자국

이전내용 : 클린코드

[인프런 워밍업 클럽 백엔드 스터디 2기] 1주차 발자국

[인프런 워밍업 클럽 백엔드 스터디 2기] 2주차 발자국

오늘은 3주차 Practical Testing: 실용적인 테스트 가이드를 시작하는 한주로 강의에 대해정리하도록 하겠습니다.

개인적으로 세션2 테스트는 왜필요한가? 라는 강좌가 제일 중요하다고 생각하였습니다.

테스트를 왜 해야 되는지?

테스트 코드는 귀찮지만, 테스트 코드를 구현하지 않는 코드는

경험과 감에 의존한다
피드백이 늦다.
유지보수가 어렵다.
소프트웨어이 신뢰성이 떨어진다 라고 전달하였습니다.
변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.
변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야된다.
빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

그렇다면 테스트 코드를 구현한 코드의 장점은

빠른 피드백
자동화
안정감
자동화 테스트를통해 비교적 빠른 시간 안에 버그를 발견하고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.
소프트웨어의 빠른 변화를 지원한다.
팀원들의 집단 지성을 팀 차원의 이익으로 승격시킨다.
가까이 보면 느리지만, 멀리 보면 가장 빠르다.

이라고 전달하였습니다.

저는 과거부터 현재까지 이어져 온 코드를 유지보수하고, 동시에 신규 개발도 진행하고 있습니다. 과거에 작성된 소스코드는 각 구성원들이 큰 책임을 가지고 유지하고 있어, 문제가 발생했을 때 사이드 이펙트나 우회하는 코드 등의 여러 요소를 신경 써야 하는 상황이 많습니다. 이로 인해 신규 입사자(신입, 경력자 모두)들이 코드를 수정하기가 매우 까다로워졌습니다. 그 결과, 작은 기능 하나를 추가할 때도 많은 비용이 소모되고, 신규 개발에 집중할 여유조차 없게 된 것입니다.

이 문제를 해결하기 위해 저는 테스트 코드를 도입하자는 의견을 제시했습니다. "우리 소스는 현재 신규 입사자들이 접근하기에 허들이 너무 높기 때문에, 문서화와 프로젝트 히스토리를 테스트 코드로 대체하자"는 것이 제 의견이었습니다. 처음에는 팀원들이 함께 구현에 동참했지만, 곧 저 혼자 테스트 코드를 작성하게 되었습니다. 워낙 업무 속도가 빠르게 진행되다 보니, 테스트 코드 도입을 강요할 수는 없었습니다.

그럼에도 제가 생각하는 테스트 코드는 코딩을 더 재미있고 확신 있게 할 수 있는 도구라는 것입니다. 신입 시절, 배포 전 문제가 생길까 긴장했던 경험이 많았고, 코드가 제대로 작동할지 확신이 들지 않았습니다. 그러나 테스트 코드를 도입한 이후에는 빠르게 피드백을 받을 수 있었고, 그로 인해 구현 과정이 훨씬 더 재미있어졌으며, 코딩에 대한 확신도 커졌습니다. 따라서 귀찮더라도 테스트 코드를 한번 작성해보고 재미를 느끼는 것도 좋다고 생각됩니다.

@Display Named을 섬세하게

테스코드를 구현하면서 제일 어려운 부분이 Display Name이라고 생각합니다. DisplayName을 상세하게 작성하지 않으면 미래에 내가 다시봐도 어떤것을 테스트하려고 하였는가 헷갈리고, 또한 문서 대신에 작성하는 테스트코드가 더 어렵게 느껴질 수 있습니다. 때문에 강의에서는 아래와 같이 예시를 들면서 전달하였습니다.

음료 1개 추가 테스트 -> 음료를 1개 추가할 수 있다.
- [
  명사의 나열보다 문장 형태로 작성하려고 노력해야된다.]
~ 테스트는 지양해야된다.
음료를 1개 추가할 수 있다. -> 음료를 1개 추가하면 주문 목록에 담긴다.
- [
  테스트 행위에 대한 결과까지 기술하는게 좋다]
특정 시간 이전에 주문을 생성하면 실패한다. -> 영업 시작 시간 이전에는 주문을 생성할 수 없다.
- [도메인 용어를 사용하여 한층 추상화된 내용을 담기]
  - 메서드 자체의 관점보다 도메인 정책 관점
- [테스트의 현상을 중점으로 기술하지 말 것 (~ 실패, 성공 등)]

지속하고 싶은 부분

제가 생각했던 부분보다 좀 더 상세하게 디스플레이 네임을 녹일 수 있게 해봐야겠다.라고 생각하였고, 디스플레이 네임이 생각나지 않는다면 지금 작성하는 글을 되돌아봐야겠다고 생각하였습니다.

아쉬웠던 점

현업이 오픈 시점이 점점 다가와서 직접 구현을 하면서 강의를 듣지 못하였지만, 그래도 강의를 보면서 어떻게 적용하면 좋을지 인사이트를 얻을 수 있어서 좋았습니다.

시도해볼 점

직접 구현해 보면서, 장점을 공유할 수 있게 습득하겠습니다.

3주차 Practical Testing: 실용적인 테스트 가이드

주요 학습 내용:

테스트의 필요성
- 테스트 코드 미구현 시 문제점
- 테스트 코드 구현의 장점
@DisplayName 작성법
- 명사 나열 대신 문장 형태로 작성
- 테스트 행위와 결과 모두 기술
- 도메인 용어 사용 및 추상화
- 테스트 현상보다 도메인 정책 중심으로 기술

가장 인상 깊었던 두 가지 개념:

테스트 코드의 실질적 가치
- 문서화와 프로젝트 히스토리 대체 가능
- 코딩을 더 재미있고 확신 있게 만드는 도구
@DisplayName의 중요성
- 미래의 자신과 동료를 위한 명확한 설명
- 테스트 의도와 결과를 명확히 전달

개선 및 실천 계획:

지속할 점
- 더 상세하고 명확한 DisplayName 작성
- 테스트 코드 작성 시 현재 작성 중인 코드 되돌아보기
아쉬웠던 점
- 현업 일정으로 인한 실습 부족
시도해볼 점
- 직접 구현을 통한 테스트 코드의 장점 습득
- 팀 내 테스트 코드 장점 공유