[TDD] 내가하는 TDD는 왜 실패하는가?

오늘 나는 개발을 하면서 그동안에 고민거리중 제일 큰 고민거리인 배포에대해 생각이 많아졌다.

 

배포 이후에 사용자들이 사용하면서 불편함을 겪을까봐 말이다...

 

그래서 오늘 강의를 하나 보게 되었다.

 

강의명  : Java/Spring 테스트를 추가하고 싶은 개발자들의 오답노트

ㄴ 다들 한번 인프런 가서 무료 강의부터 먼저 들어보세용

 

---

 

여기서 하는 말중에 공감가는 말이 있었는데..

 

강사 曰 : 내가 개발하거나 수정한 코드가 이미 잘 돌아가는 기능들에 영향을 줘서 서비스 장애가 날까봐 겁난다는 얘기에요.. 

 

나 曰: ㅠㅠ 맞다..

 

요약하면 이런 문제를 '회귀(Regression) 버그'라 부른다.

> 잘 동작하는 기능들이 이번 배포로 인해서 동작하지 않던 시절로 회귀하는 그런 버그

> 이런 회귀버그 때문에 팀원들이 자신감을 갖고 배포를 못하는 것.

>> 업부 대부분의 시간을 인수 테스트하는 데이 너무 많이 쓰이는 것.

>>>  그래서 회귀버그의 아주 효과적이라는 테스트 자동화를 해보자라고 생각하게 된다.

 

-

1. 레거시 코드에 테스트를 넣는게, TDD가 아닙니다.

2. 레거시에  테스트를 넣으려면 코드 개선이 필요합니다.

- 테스트의 목적

>>회귀 버그 방지

>>유연한 설계로 개선

>>>테스트를 쉽게 만들어줌

>>>테스트를 결정적이게 만들어줌

3. 커버리지에 집착하면 안됩니다.

> 코드를 짜다 보면 생각보다 테스트가 필요없는 부분이 생김.

>>테스트를 추가했을 때 얻을 수 있는 효용성을 생각해 봐야지! 커버리지 자체가 목적이 되어 버리면 안된다.

>>> 왜? 테스트를 통해 얻을 수 있는, 수많은 장점을 놓치게 될 수 있다.

> 그동안 우리는 mock 프레임워크나 jUnit을 어떻게 잘 사용할지만 고민했던 거다

>> 핵심 가치를 이해야한다.

---

테스트란?

인수 테스트와 자동 테스트가 있다.

> 인수 테스트 : 사람이 직접 사용해 보면서 준비된 체크리스트를 체크하는 인수 테스트

> 자동화 테스트 : 미리 짜여진 테스트 코드를 가지고 결과값이랑 예상한 값을 비교하는 자동화 테스트

>>> 이런 상황이 발생했을때(given) / 이렇게 호출하고(when) / 이렇게 된다.(then)

ㄴ 방법중 스프링 JPA를 사용했을때 h2를 사용하여 oracle 등 같은 RDB를 인메모리에 잠깐 띄운 후 테스트하는 솔루션(예 : 저장이 잘되는지)

# 결과

> 커버리지를 올리기위한 MOCK프레임워크 사용법만 고민하고

>> 왜 테스트를 해야하고,  어떻게 테스트 해야하는지 고민하지 않았기 때문

#해결책

> 방향성 : TDD를 논하기 전에 테스트가 가능한 구조로 변경 되어야 한다.