[인프런 워밍업 스터디 클럽 2기_BE] 3주차 회고록 정리

테스트 코드를 작성하지 않음으로써의 문제점

변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야한다.
변화가 생기는 매순간 마다 모든 팀원이 고민을 해야한다.
빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.

근데 테스트 코드가 더럽다면?

프로덕션 코드의 안정성을 제공하기 힘들어짐
테스트 코드 자체가 유지보수하기 어려운 짐이된다.
잘못된 검증이 나올수 있다.

가까이 보면 멀어보이지만 , 멀리서 보면 빠르다.

단위 테스트 도입

여기서 단위 테스트란?

작은 코드 단위를 독립적으로 검증하는 테스트 ( 클래스 or 메서드 )
검증 속도가 빠르고 안정적이다.

JUNIT5

테스트 단위를 위한 테스트 프레임 워크

AssertJ

테스트 코드 작성을 원할하게 돕는 테스트 라이브러리
풍부한 API 메서드 체이닝 지원!

TDD란?

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

Red-Green-Refactor

실패가 되는 테스트 작성
테스트 통과 최소한의 코딩 - 일단 굴러만 하기만 하면된다.
구현 코드 개선 테스트 통과 유지

1,2,3번 사이클이 계속 돕니다.

테스트→ 기능 → 테스트

기능을 먼저하면

테스트 자체의 누락 가능성
특정 테스트 케이스만 검증할 가능성
잘못된 구현을 다소 늦게 발견할 가능성

테스트를 먼저 작성하려면? → 요구사항분석과 테스트 단위를 잘 쪼개야한다.

테스트를 하기 위한 구조생각이 떠오를 수 있다.

클라이언트 관점에서의 피드백을 주는 Test Driven

[]은 뭘까..

내 생각은 철저한 요구사항이라고 생각한다.

강의에서는 문서! 라고 하는거봐서 유사하다고 생각했다.

문서?

프로덕션 기능을 설명하는 테스트 코드 문서
다양한 테스트 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완
어느 한 사람이 과거에 경험했던 고민의 결과물을 팀 차원으로 승격 시켜, 모두의 자산으로 공유 가능

팀으로 일하기 때문에 팀이 보기 편하게 봐야한다!

잘보려면 어떻게 해야할까?

저번 강의에 대해 추상화 레벨을 맞춰 가독성을 좋게하는게 포인트다!

마찬가지로 문서를 보기 편하게 하기위해 테스트 코드에서는 DisplayName이 있다!

Displayname은 구체적으로 섬세하게 작성해야한다.

Persistence Layer

타 ORM으로 변경될 수 있기 때문에 이를 보장하기 위해 테스트를 진행해야 한다.

미래에 어떤 형태로 변할지 모르기 때문에, 이러한 가능성에 대비해 테스트를 확실히 해야 한다.

Business Layer

비즈니스 로직을 구현하는 역할
Repository와 상호작용을 통해 비즈니스 로직을 전개
트랜잭션을 보장해야 한다

비즈니스 레이어 테스트는 레포지토리 테스트와 함께 작성하는 것이 목표이다.

테스트를 위해 Request 객체를 생성자로 만들어 놓는 경우도 있다.

Order 계산 부분에 대한 테스트가 필요할 것이라는 생각이 중요하다.

서비스 로직에서는 등록 시간을 처리하기 어려울 수 있는데, 이 경우 파라미터로 시간을 받아 작업하는 것이 좋은 방법이다.

메서드 단위 테스트는 메서드를 잘 나눠야 나중에 테스트하기 편하다.

테스트를 동시에 실행할 때 하나는 성공하고 다른 하나는 실패하는 이유는 중복된 동작이 영향을 주기 때문이다.

따라서 매 테스트마다 초기화를 진행해야 한다.

Teardown 순서가 올바르지 않으면 문제가 생길 수 있다.

@DataJpaTest와 @SpringBootTest의 차이는 트랜잭션의 차이로, 자동으로 롤백 처리가 된다.

직접 트랜잭션을 설정하면 롤백이 되며, 나중에 강의에서 문제에 대해 설명해 준다.

간단한 테스트도 언제든지 바뀔 수 있기 때문에 미래를 대비한 테스트가 필요하다.

Deduct 체크를 진행할 때 왜 두 번 검증할까?

서비스 검증과 도메인 검증이 별개의 역할이라고 판단하여 두 번 진행하는 것이다.

요구사항을 정확히 파악하고 테스트 케이스를 분리하는 것이 좋다고 생각했다.

예외 케이스에 대한 테스트도 반드시 진행해야 한다.

과제

테스트 코드를 작성하는 것은 너무 생소하고 강의를 들었을때랑 내가 직접 작성하면서 했을때랑 떠오르는게 다르다 생각했다. 그리고 조그만한 테스트도 해야하나? 라는 고민도 많았고 기존에 했던 Readable보다 더 오랜 생각을 했었던 것같다. 테스트 코드를 작성 후 이후 강의에 대한 내용을 들어보고 나서 역시 모든 케이스는 커버를 해야된다라는 생각이 들었다.

회사에서는 직접적으로 테스트 코드를 도입하지 않았지만 강의를 듣고 공부를 진행하면서 테스트 코드의 세분화를 잘해야할꺼같다.