[OKKYCON: 2018] 이규원 - 당신들의 TDD가 실패하는 이유

• 발표자: 이규원님
• 세미나 영상
• 발표 자료

개요

• TDD를 성공적으로 적용한 경험을 토대로 말할 예정이다.
• 현재 우리 프로젝트는
  • Non-startup
  • Business Service
  • Global Market
  • Competitors
  • Message-Driven
  • Multitenancy
  • Scalable
  • Responsive
• 현재 팀은 1년차, 신입 2명이 있음
• 이러한 현업 경험이 거의 없는 팀원들과 위 요구사항을 어떻게 해나아갔을까?

TDD가 실패하는 이유?

• 실패하는 이유? "너희는 준비가 안됐다."
  • 성급하게 도입하고 성급하게 결과를 보려한다.

개인이 실패하는 이유(이렇게 하지 않아서 실패했을 것이다.)

• 과학과 엔지니어링의 차이
  • 과학은 진리를 탐구하는 것이다.
  • 엔지니어링(프로그래밍)은 과학과 예산 사이에 균형을 맞추는 것이다.
• 왜 TDD를 하는 사람은 모든 코드를 TDD로 하려 하는가?
  • "우린 안그러는데?"
  • TDD를 많이 하지만 모든 것에 하지는 않는다.
  • 과학자가 아니라 엔지니어이기 때문이다.
  • TDD를 통해 안정적으로 만들 수 있다면 적용한다.
  • 그렇지 않은 것은 하지 않는다.
• 다른 테스트기법도 많다.
• 내가 혹은 팀이 준비가 안되어있으면 TDD를 적용하지 않는 것이 좋다.

우리가 보호해야 하는 것(어디에 TDD를 적용해야 하는가?)

• AWS
• 스프링
• 도메인
  • 비지니스에 필요한 문제들을 모아놓은 것

어떻게하면 도메인에 투자할 수 있을까?

• 우리가 제어할 수 없는 것에 투자하지 않는다.
  • 외부 세상
    • 실 세계(불명확한 비지니스 요구사항, 상사의 기분, ...)
    • 인프라
    • 외부 서비스
    • 레거시
• 설계
  • 낮은 결합
  • 높은 응집
  • 도메인 모델 보호
• 설계를 테스트하라
  • 설계를 변경하면 기존의 테스트코드가 다 깨진다...
  • 그런데 아닌데도 있다.
  • 여기는 비지니스 로직이 안바뀌는 곳일까?
  • 그렇진 않다.

TDD를 실패하는 사람들의 테스트는 구현을 테스트한다.

• 구현 테스트

• 테스트가 내부를 쏙쏙히 알고 있다.
• Mock을 많이 사용하면 생기는 부작용 중 하나이다.
• 프로덕션을 변경할 때마다 테스트 코드를 변경해야 한다면 비용이 매우 커진다.(다양한 도형을 네모 도형으로 리팩토링)

---

• 정보 숨김(Information Hiding)
  • David Parnas, 1971
  • 어려운 설계 결정과 변경될 가능성이 높은 설계 결정들을 다른 모듈로 부터 숨기는 것
  • getter/setter로 숨기는 것을 말하는 것이 아니다.
• 설계 테스트

• 더러운 설계 -> 네모 반듯한 것으로 바꾼것
• 인터페이스를 테스트한다.
  • 내부가 변경되더라도 테스트는 깨지지 않는다.
• 어디까지가 implementation인가?
  • 이는 캔트백도 어렵다고 했다.

레거시와 함께 살기

• 이전 직장에서 일할 때 설계 결합도가 높고, 테스트 자동화가 거의 안됐다.
  • 여기서도 레거시코드를 가지고 TDD를 했다.
  • Adapter 레이어를 만들었음
  • 이 레이어는 테스트를 하지 않고, 최대한 단순하게 만든다.
  • 팀이 아닌 혼자서 TDD할 때 썼던 기법이다.
• 개인이 TDD하는 것과 팀이 TDD하는 것과는 다른 이야기이다.

당신의 팀에서는 이렇게 하지 않는다.

• 프로세스
  • 점진
  • 반복
  • Fail-Fast
• 소프트웨어는 항상 성공하지 않는다.
  • 답을 모르는 것들이 대부분이기 때문
• 가능한 실패를 빠르게 해보는 것이 해결하는데 더 빠를 수 있다.
• 반복주기
  • 계획
  • 실행
  • 평가(테스트)
• 대부분 실행만 한다.
• 문화
  • 공유
    • 목표: 제일 중요함, 어디로 가야하는가, 팀 사이에 확실히 공유되어야 함
    • 지식
• 아키텍처
  • 낮은 결합
  • 높은 응집
  • 도메인 모델 보호

도메인 모델과 플랫폼

• 자바가 항상 스프링을 얘기하는 이유가 플랫폼 안에 도메인 모델이 있다.(강하게 결합하고 있음)
  • 모든 코드에 스프링이 박혀있어 스프링 얘기밖에 할 수 없다.
  • Autowired 등

• 플랫폼과 도메인은 독립적이어야 한다.
  • 플랫폼은 도메인을 호스팅하는 역할만 해야 한다.

• 아키텍처 사례
  • 라이브코딩에 사용할 모델
  • 뭐가 뚱뚱한지 봐야한다.
  • 비지니스 모델에 가장 많은 코드가 있고 복잡하다.
  • 서비스 계층에서 외부 플랫폼(카프카, 스프링 등)이 의존한다.(비지니스 로직과 의존하지 않음)

• MVVM 아키텍처
  • UI 앱에서 쓰이는 모델
  • 테스트하기 힘든 View 레이어가 가장 얇고 코드가 많이 없어야 한다.
  • View 코드가 없어질 수 도 있다.

라이브 코딩

• 세미나 영상을 직접보는 것이 좋을 듯 하다.
• 목적
  • 소프트웨어 사용자에게 어떤 가치를 전달할 것인가?
  • 개발자에게는 매우 구체적인 요구사항이 필요하다.
• 그림을 그리는 것은 의사소통에 중요하다.
  • 목적 공유에 중요
• ATDD + TDD
• 주니어와 코딩뿐 아니라 유저스토리, 태스크를 짜는 것까지 페어를 해보면서 주니어를 키울 수 있었다.
  • 효과는 굉장히 좋았다.