TDD 이야기토스랩 Steve 승욱 정

Java Spring Framework Study

TDD 첫 맛남

뭔지는 모르겠고…시키니깐 우선 해보자

TDD 해보자!

1. 안드로이드 테스트 환경 구성

2. 안드로이드 테스트 해보기3. 테스트 클래스 작성..또 작성…계속 작성….

TDD 노가다

모르니깐 그냥 해보자

모든 파라미터 Null 체크모든 if 문 테스트모든 경계값 테스트

UI 테스트까지…

그 결과는?

테스트 커버리지 80% 이상

그때 기억으로는 ...

UI 테스트까지 해서 80% 가 넘는 커버리지…

지금 생각해도 쉽지 않은 일무식하면 용감하다지요 ...

Test 코드 작성에 대해 많이 생각

1. 모든 코드를 테스트 할 필요 없다

코드의 흐름상 뻔한 값이 나올 수 밖에 없는 상황…(return 1 메소드를 테스트 할 이유가 있나?)

Controller 의 테스트보다는 Model 의 테스트가 더 중요함(급하다면 Model 테스트가 먼저)

2. UI 테스트는 생명 주기가 너무 짧다.

사용성, UI 개편에 따라 일반적인 로직에 비해 생명 주기가 너무 짧다.하면 좋으나 테스트코드가 얼마나 살아 있을지에 대해 고민해보자

3. 테스트 안되는 코드는 없다!!

return void????어떤 메소드든 결과 값을 만들어 낼 수 있다!!

너무 긴 메소드는 10 중 8,9 한가지 로직에 충실하지 않다.이러면 테스트가 거의 불가능...우선 쪼개자

테스트를 위한 분리로 리팩토링이 자동으로 습득됨(주니어에겐 더할나위 없이 좋은 학습)

4. 커버리지 측정 한번 해보자

내가 테스트 코드를 잘 작성하는지에 대한 객관적 지표

덤으로 측정값이 올라갈 때마다 레벨 업 하는 느낌..

5. 경험이 쌓이면 예외 처리 능력도 향상된다.

테스트 코드를 작성하면서 놓쳐버린 예외에 대해 각인

이게 Null 이더라도 Default 는 이걸로…실패 케이스에 대해 언제나 염두

6. 생각보다 개발 시간이 소요되지 않는다

개발자 테스트 시간이 절약QA 후 이슈가 적음

(경험적으로 80% 이상 커버리지 획득한 서비스는 1년간 VOC 가 거의 없었다..)

5분간 휴식

한동안은 테스트 작성 안함

귀차니즘 + 개발도 빠듯한 일정이라는 핑계...

TDD 다시 해볼까?

Android 빌드 환경의 변화

Ant -> Gradle

Gradle 파악 겸 Robolectric* 검토

*Robolectric : 안드로이드를 JVM 상에서 테스트 가능하도록 도와주는 테스트 프레임워크

미친 듯이 검토...공부…

Gradle 공부 하랴Robolectric 공부 하랴...

1달간 매일 3~4시간 공부 한듯...다크서클...ㅠ

정신 차려 보니???

Robolectric 기여자

내 코드가 반영되는 그 짜릿함…(사실 이걸로 1년째 우려먹는 중…- _-)

지금은 Roboletric 으로신나게 테스트 중...

이라고 생각 했는데 커버리지가 20% 미만…아 부끄럽다...ㅠ

정리

1. TDD 는 해서 손해볼 것 없다

1. TDD 는 해서 손해볼 것 없다2. 코드의 신뢰성을 높이는 과정

1. TDD 는 해서 손해볼 것 없다2. 코드의 신뢰성을 높이는 과정3. 서비스의 안정성을 높이는 과정

1. TDD 는 해서 손해볼 것 없다2. 코드의 신뢰성을 높이는 과정3. 서비스의 안정성을 높이는 과정4. 테스트는 QA 만의 몫이 아니다.

1. TDD 는 해서 손해볼 것 없다2. 코드의 신뢰성을 높이는 과정3. 서비스의 안정성을 높이는 과정4. 테스트는 QA 만의 몫이 아니다.

잊지말자

오류의 99%는 내 손에서 나온다...