TDD?
켄트백 曰:
사람은 한 번에 두 가지 일을 하는 것은 어렵다.
한 번에 한 가지만 집중해야만 한다.
- Red 1단계 : “문제를 정의하는 것에 집중한다.”
- Green 2단계 : “그 문제를 해결하는데 집중한다.”
- Blue 3단계 : “작성한 코드를 Clean Up하는 것에 집중한다.”
이 3단계 주기가 빈번하게 전환되어야 한다고 합니다.
위에 Red, Green, Blue cycle 에서 Red 단계에서 Failing test 를 작성하는 시기가 가장 중요하다고 생각합니다
그 이유는 요구사항이 무엇인지 다시한번 생각해보고 방향을 틀수있는 마지막 기회이기 때문입니다.
TDD 장단점
TDD 에 대해서 간단히 맛을 보기 위해선 백명석님 클린 코드 강의 중 TDD편을 보시는 것을 추천드립니다.
(로버트 C 마틴 Advanced TDD 강의를 토대로 설명한 강의입니다.)
| 장점 | 단점 |
|
디버깅 타임 (유닛테스트 환경에서 버그를 손쉽게 찾아낼 수 있습니다.) |
생산성 저하 (코드 퀄리티 보다는 빠른 결과물을 원하는 환경이라면 쉽게 도입이 어려울 수 있습니다.) |
|
잘 디자인된 문서 (미리 TestCode 에서 Client의 사용 코드를 작성해봄으써 좋은 디자인이 될 수 있습니다.)
|
|
|
decoupling (모든 객체가 의존성 주입을 받아야 하기 때문에 결합도가 낮아집니다.) |
|
|
변경을 두려워하지 않는다. (Test Code를 성공시키면서 공격적으로 코드를 변경할 수 있습니다.) |
"잘 디자인된 문서"
예전에 Bitcoin 이 붐이 되면서 Bitcoin 의 코드를 경험해보기 위해서
가장 먼저 한 일은 Bitcoin Github 에서 테스트코드를 실행해본 경험이 있습니다.
문서가 코드 안으로 들어오면서 합의 알고리즘 스펙을 빠르게 파악할 수 있었습니다.
"변경을 두려워하지 않는다"
마틴 파울러 저 리팩토링 Expense 예제에서 Test Code 가 있는 상태에서 코드를 리팩토링 해나가는 과정을 해볼 수 있습니다.
해보시면 상당히 재밌습니다. 해보시는 것을 추천드립니다.
TDD 설계의 중요성
TDD 를 적용할 수 있으면 적용하는 것이 소프트웨어 품질 향상에 이득이 된다고 생각합니다.
그러나 경우의 수가 나오는 경우 100번째 테스트코드를 성공해도 101번째 깨지게 됩니다.
여기서 말하는 경우의 수란 if, range(구간) 등 을 말하고 있습니다.
또, 500일동안 버그가 없었지만 501일날 버그가 발생할 수 도 있습니다.
단순히 TDD 를 할 수 있다 없다가 아니라 책임주도개발의 협력 문맥에서 설계가 잘 되어있어야만 TDD 를 달성할 수 있다고 생각합니다.
그러나 TDD 를 하면서 객체 디자인을 할 수 있는 사람은 켄트백 수준까지 올라가야한다고 합니다.
RIBs 와 TDD
Let's swift 에서 MVC, MVVM, ReactorKit, Viper를 거쳐 RIB 정착기 발표에서 테스트코드에 대해 많은 이야기를 해주셨습니다. 👏
아래내용은 MVC, MVVM, ReactorKit, Viper를 거쳐 RIB 정착기의 내용입니다.
기존 아키텍처에 왜 만족 못했는가?
- 기존 기능 수정 및 확장 어려움
- Swift 2 시작해서 Swift 이해도 낮음
- 당시 아키텍처의 표준화된 틀이 없음
- 유연하지 않은 설계로 인한 확장의 어려움
- 화면 단위가 아닌 프로세스 단위로 유연한 개발 필요
- Viewless 아키텍처가 필요
- ReactorKit, Redux, Coordinator 아키텍처 참고
- 하지만 한 곳에서 많은 로직을 처리하게 코드가 변질됨
- 재사용 어렵고 새로운 비즈니스 로직을 넣기 어려움
- 자체 제작 아키텍처의 유비보수 어려움
- 은행앱이기 때문에 더 확실한 안정화 필요
- 바쁘다는 핑계로 테스트를 제대로 못했던 문제
- 테스트코드 템플릿 또는 가이드가 있는 아키텍처가 거의 없음
[스몰토크] 시스템 아키텍처 요구사항의 가치를 가장 높게 두다.
항공, 원자로 관련 시스템와 같은 latency 를 빨라야 한다는 요구사항이 있다면 그것을 중점에 두고 설계를 할 필요가 있습니다.
경영진이 중요한 의사결정을 하기 위한 경영 지원 시스템을 만든다면 latency 가 느려도 정확성의 가치가 높습니다.
은행앱의 높은 안정성을 요구하는 시스템 아키텍처 요구사항이 있습니다.
사람들의 생각은 모두 다르기 때문에 표준을 정하고 시스템 안정성을 취하기 위해 RIBs 로 가는 것은 적절하다고 생각이 듭니다.
[스몰토크] Getting stuck
로버트 C 마틴은 요구사항의 문제를 해결하는 과정에서 0 -> 1 -> 2 -> N과 같이 점진적인 개선이 되는 것이 TDD의 가장 중요한 원칙이라고 소개합니다.
만약 최초부터 어려운 문제를 정의하고 해결한다면 그 이후로 나오는 문제를 해결 할 수 없는 상황이 발생할 수 있습니다.
이러한 상황은 ”Getting stuck”이라고 정의하며, 이 경우 두 가지 탈출 방법이 있습니다.
- 처음부터 다시 짠다.
- Production Code가 잘 동작하도록 수정한다.
[스몰토크] 선개발 후테스트코드
개발 속도를 빠르게 올리면서 안정성을 취하기 위한 전략으로 선개발 후테스트코드를 선택할 수 있습니다.
이미 개발이 완료된 Production code 에 대해 테스트코드를 작성할려니 서로 얽혀있기 때문에
테스트코드를 작성할 엄두가 나지 않게 됩니다.
참조:
http://www.yes24.com/Product/Goods/7951038?scode=032&OzSrank=1
'iOS > 스몰토크' 카테고리의 다른 글
| [스몰토크] Swift Stubbing 통합테스트 (1) | 2019.11.26 |
|---|---|
| [스몰토크] Clean Architecture? Clean Swift (VIP)? (0) | 2019.11.25 |
| [스몰토크] WKWebView 와 통신 어떤것이 적절할까? Scheme VS Bridge (0) | 2019.11.20 |
