패스트캠퍼스 챌린지 32일차

Part 1. Spring Framework

Ch 05. 예외처리

01. 테스트를 잘 하는 방법

- SI 때 혹은 과거의 경험 (강사님)

-- 테스트는 모두 사람이 하는 것이었고, 한번의 테스트는 상당한 노동력을 필요로 했음

-- SI에서는 전용 테스트 팀이 따로 있었고, 인수인계 전에 인수테스트라는 것을 진행해서

기능적인 테스트를 꼼꼼히 했었음

- 그러다가 불어온 테스트의 바람

-- 하지만 로직이 대부분 쿼리에 있는 mybatis에서는 테스트하기가 상당히 까다로웠음

-- 그 후 시간이 지나 JPA를 하게 되고, 쿼리가 아닌 자바 코드에 로직이 많이 담기게 됨

--- 유지 보수성의 극적인 향상 (쿼리로는 다형성이나 디자인패턴 전략 등을 하기 어렵거나 불가능)

--- 자바코드에 담긴 로직은 쿼리에 담긴 로직에 비해 테스트하기 상대적으로 편리함ㅁ

- TDD & 실무

-- 처음 공부해보고 도입하려고 해보았으나, 클래스의 구성이나 프로그램 구조가 잡히지 않은 상태에서는 어려웠음

-- 여러가지로 공부해보고 실무나 주변을 본 결과

완벽한 의미의 TDD (일단 테스트 먼저 짜고 코드를 만드는 것)은 어려움

- 테스트를 잘 하기 위한 기반

-- 클래스나 메서드가 SRP를 잘 지키고, 크기가 적절히 작아야함

--- 그래야 테스트를 집중력 있게 만들 수 있고 한 메서드에 너무 많은 테스트를 수행하지 않아도 됨

--- 이게 테스트를 하는 것의 장점이 되기도 함 (테스트를 하면 자연스럽게 역할이 확인되면서 쪼개짐)

-- 적절한 Mocking을 통한 격리성 확보

--- 단위테스트가 만능은 아니지만, 위의 SRP처럼 해당 메서드의 역할을 정확히 테스트하려면

주변 조건을 적절히 통제해야함

-- 당연히 잘 돌겠지라는 생각말고 꼼꼼히 테스트

&& 너무 과도하게 많은 테스트와 코드량이 생기지 않도록 적절히 끊기

--- 테스트코드도 코드 리뷰 시에 적절한 테스트를 하는지 확인 필요

-- 테스트 코드 개선을 위한 노력

--- 테스트코드도 리팩토링 필요

--- 테스트코드의 기법들도 지속적인 고민 필요(통합테스트)

https://bit.ly/37BpXic

.