오늘은 직접 간단한 @Test 예제를 통해 직접 테스트를 해보고, 왜 이 테스트가 필한지 이 리팩토링이 왜 필요한지를 직접 몸으로 느끼게 되었다.
개발자의 입장에선 불필요한 자원의 낭비나, 내가 구상한 방향으로 flow가 진행되지 않는다면 잘못된 결과를 초래할 수 있는데, 이는 곧 책임에 맞지 않는 코드를 사용하는 것과 같은 맥락이다.
보통 main() 메서드에 해당 메서드에 값을 전달해서 찍어보는 방식을 사용하거나 @slf4j라는 log를 찍도록 도와주는 어노테이션을 사용해서 올바른 데이터가 들어오는지 등 방식을 사용했다. 물론 이러한 방식이 잘못되었다는 것은 아니나, 만약 코드가 엄청 복잡해지고, 길어진다면? 과연 코드만 분리한다고 해서 우리가 가진 근본적인 문제를 해결할 수 있을까? 등 여러 고민들과 난관에 봉착하게 되었다.
그래서 테스트코드를 직접 작성하고, 해당 결과를 확인하면서 얻은 인사이트는 다음과 같았다.
- 테스트 코드를 메소드별 독립적으로 시행 가능하다는 점 -> 이로서 프로덕션 코드에 집중할 수 있음
- 테스트 코드 실행 시 @Before과 @After가 각각 실행되어서 객체를 생성한다는 점 (메서드별 전처리, 후처리)
앞으로 이 @Test 어노테이션과 테스트를 잘 활용해서 내가 원하는 기능을 정확히 만들어 냈는지를 확인해야겠다는 하루였다. ( 테스트 코드를 작성하고 추후 리펙토링을 진행해 코드의 품질을 높이는 방식으로 가는 것이 좋겠다. )
2022.12.27 - [독후감/자바 웹프로그래밍 Next Step] - Chapter 2 테스트와 리팩토링
참고자료 :
https://junit.org/junit5/docs/current/user-guide/#writing-tests-test-execution-order
'TIL(Today I Learned)' 카테고리의 다른 글
Day.41 - 금일의 학습 내용 - (1) | 2023.01.11 |
---|---|
Day.40 밀린 TIL 그리고 학습 요약 (0) | 2023.01.10 |
Day.38 Stream 그리고 for (0) | 2022.12.27 |
Day.3N 밀린 TIL (0) | 2022.12.22 |
Day.34 + 35 고민, 그리고 의미 있는 데이터란? (0) | 2022.12.16 |