OKKY The Real TDD 후기

테스트하기 쉬운 코드로 개발하기 - 정진욱님

테스트하기 쉬운 코드란?

같은 입력에 항상 같은 결과를 반환하는 코드 - Deterministic
- 항상 결과가 같지 않는 코드란?
  - 시간에 의해 결과가 결정되는 함수.
    - 오늘 날짜를 구하는 함수
  - DB의 의해 결과가 결정되는 함수.
    - 전체 회원의 수를 구하는 함수
외부 상태를 변경하지 않는 코드 - No side effect
- 외부 상태를 변경하는 함수란?
  - Console.WriteLine(result);

테스트 시나리오는 어떻게 작성할까?

유효성 검사
- Email : @가 포함되었는가?
- 이름 : 숫자가 포함되었는가?
- ConferenceId : 음수인가?
이미 등록된 좌석 수 DB에서 읽어오기
요청한 좌석 수가 확보 가능한지 판단하기
- 잔여 좌석수(전체 좌석 수 - 등록된 좌석 수) >= 요청한 좌석수
- 한꺼번에 10좌석을 초과해서 등록할 수 없다.
등록 정보 저장
HTTP 결과 반환

위 테스트 시나리오 중 테스트하기 어려운 부분 어느 곳일까?

이미 등록된 좌석 수 DB에서 읽어오기
- DB는 항상 같은 입력(Query)에 항상 같은 결과를 반환하지 않는다.
등록 정보 저장

외부 상태에 의존적인 코드.

어떻게 이 문제를 해결할까?

테스트하기 쉬운 코드와 어려운 코드를 분리하자.
- 외부 상태에 의존적인 부분이 어디인지 확인하고 분리하자.
  - DB를 조회하는 부분
  - 테스트 데이터를 넣고 테스트.
외부 상태에 의존 적이지 않는 코드
- 즉 테스트를 하기 쉬운 코드는 도메인 객체에

테스트하기 쉬운 코드와 테스트하기 어려운 코드가 만나는 부분을 최대한 end-point(controller) 쪽으로 작성하여 결합도를 낮춘다.

TDD 맛보기

이메일에_골뱅이가_없으면_유효하지_않은_형식입니다(){
    //Arrange
    var sut = new ConferenceRegistration{Email = "nesoy.gmail.com"};

    //Act
    string actual = sut.validate();

    //Assert
    Assert.Notnull(actual);
}

TDD로 code를 작성할 때 주의할 점.

테스트를 만족하는 만큼만 코드를 작성하자.
- 그 이상 코드를 작성하게 되면 테스트로 커버할 수 없다.
- 즉 코드의 변경되는 부분을 놓칠 수 있다.
- 작게 작게 변경되는 부분에 집중하고 Cover하자.

두 부류 코드(테스트 하기 쉬운 코드, 테스트 하기 어려운 코드)가 만나는 Edge에서 어떻게 테스트하는가?

수동 테스트
- curl, Postman
자동 테스트
- DB에 테스트 데이터를 저장하고
- POST로 API를 호출합니다.
- 결과 값을 검증하는 과정을 진행합니다.

Mock 사용 한다는 건?

작성된 코드사용을 강제할 수 있다.
Mock을 통해 이음새(Seam) 도입
행위 검증(mock)
- 어떤 메소드가 호출되었는가?
- 추상화가 필요함. -> 불필요한 추상화가 필요
- Outside-in
상태 검증(value)
- 결과 값이 무엇인가?
- 불필요한 추상화 필요없음.
- 구현된 코드에만 의존하기 때문에 실제로 데이터가 필요.
- Inside-out

Mock의 단점은 무엇일까?

Mock이 사용하기 쉬우니 남발할 가능성이 크다.
- 대부분 Mock 사용 예제는 간단하다. 그래서 장점이 크게 보인다.
- 실제 프로젝트에 적용하면 한꺼번에 많은 수의 Mock을 다루면서 곤란을 겪는다.
적당 수의 Mock 사용에 대한 답을 찾기 어렵다.
때로는 상태 검증으로 돌아가보자.

Mock을 대신하여 상태 검증를 한다는 것은?

TDD를 통한 사전이 아니라 사후 테스트를 하자.
난해한 코드가 아니다.
구현된 코드를 사용하지 않고 굳이 어려운 길을 택할 이유가 없다.
완벽을 추구하면서 Mock을 사용하는 비용을 들일 필요가 있는가?

정리하자면?

테스트하기 쉬운 코드란?
- 항상 같은 결과 반환
- 외부 상태를 변경하지 않는 코드
테스트하기 쉬운 코드로 개발하기
- 테스트하기 쉬운 코드와 어려운 코드 분리
- 두 부류의 코드는 최대한 가장 자리에 위치(예외: 로깅, 퍼사드)
- 테스트하기 어려운 코드를 최대한 가장자리에서 만나게 만들자.
  - endpoint

Reference

Jin-Wook Chung’s blog

후기

과도한 Mock은 정답이 아닌듯 하다.
Mock과 상태 검증 적절히 사용하는 것이 중요한 Point라고 생각된다.

의식적인 연습으로 TDD, 리팩토링 연습하기 - 박재성님

TDD < Refactoring

의식적인 연습이란?

무조건 연습을 많이 한다고 잘할 수 있을까?
- 테스트하기 쉬운 코드와 테스트하기 어려운 코드를 보는 눈
- 테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 감(sense)
- 목적 의식 있는 연습에 얼마나 많은 시간을 투자했느냐?
  - 1만 시간의 재발견
- 구체적인 목표 세우고 실행하기
- 피드백과 피드백에 따른 행동 변경을 수반

의식적인 연습으로 TDD, 리팩토링 연습 과정

단위 테스트 연습
- 사용하는 API 사용법을 익히기 위한 학습 테스트 작성 시작
- xUnit의 사용법을 익힐 수 있다.
- 사용하는 API에 대한 학습 효과가 있다.
- input과 output이 명확한 클래스 메소드(보통 util 성격의 메소드)
TDD 연습
- 토이 프로젝트로 시작하기
- 의존관계가 없는 프로젝트로 시작하기
Refactoring 연습
- Method 분리하기
- Depth가 2단계 이상
- Else를 안 쓰는 연습
- Method는 항상 SRP를 지켜야 한다.

한 번에 한 가지 명확하고 구체적인 목표를 가지고 연습하라. 연습은 극단적인 Rule을 세워 연습하는 것도 좋다. 그래야 insight도 생긴다.

극단적인 Rule이라면?

일급 Collection만 사용하기.
3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
점진적으로 요구사항이 복잡한 프로그램을 구현한다.

의존관계 추가를 통한 난이도 높이기

앞 단계 연습을 잘 소화했다면 테스트하기 쉬운 코드와 어려운 코드를 분리하여 연습하기
ATDD 기반으로 응용 애플리케이션 개발하기
컴파일 에러를 최소화하면서 Refactoring

Book

Question

comfort zone을 나오는 노하우는 있으신지?
- 시간과 마음적인 여유 확보하기.
- 확보한 시간과 여유로 의식적인 연습하기.
요구 사항이 변경되는 경우 테스트 변경 또한 많은 경우에는 어떻게 해야할까?
- 제대로 설계가 안된 경우.
  - 설계에 다시 고민하고 생각하기.
- 변경이 한 곳으로 집중되어야 한다.

후기

가장 재밋게 듣고 이해와 공감이 많이 가는 강의였다.
시간이 괜찮다면 Toy Project로 시작해봐야겠다.
- 우선 시간과 여유 확보하기.

코드 품질을 위한 테스트 주도 개발 - 한성곤님

TDD란?

Fail Test
Write Production Code
Refactoring

From Test

동작하는 코드에 대한 자신감
회귀테스트를 통한 자유로운 리팩토링
코드에 대한 지식이 증가
개발 생산성 향상

From Test-first

과도한 설계를 피하고, 간결한 interface를 가짐
불필요한 기능(Gold-Plating)을 줄임
실행 가능한 문서(Executable documents)를 가짐
코드 품질을 높임

TDD Metric

Software Quality
- External Quality + Internal Qulity
Internal Qulity
- Coding Rules : 개발 표준 및 기본적인 관례 준수
- Potential Bugs : Inspection을 활용한 점검
- Comments : 적정한 주석, Public Method만 확인
- Duplication : DRY
- Complexity : 적절한 분포
- Unit Tests : Lack of Unit Test

후기

생각보다 측정하는 방식이 다양하고 측정하는 Metric 또한 너무 많았다.
단순히 Coverage가 높다고 좋은 Software는 아니라고 말씀해주신게 기억이 남는다.

테알못 신입은 어떻게 테스트를 시작했을까? - 이혜승님

이미 테스트 하기 쉽게 만들어져 있는 코드로 시작한다.
- 순수 함수
- 외부 의존성(Dependency)이 없는 함수.
- utility, helper
테스트 하기 어렵게 만들어져 있는 코드에서 테스트 하기 쉬운 것만 분리하기
- 중요도가 높은 비즈니스 로직이 포함된 부분
- 버그가 발견된 부분(과거 X)
- 결합이 낮고 논리는 복잡한 부분
외부 의존성을 제거하기 위해 Parameter로 작성하기.
중요도가 높은 비즈니스 로직부터 시작하기.

TDD의 좋은 점은?

불안감이 제거된다.
스펙 문서 가능
- 실제로 파라미터 뭐가 있는 지, 반환 값은 어떤 모양인지 등 스펙을 확인할 때 테스트 코드를 봅니다.
디자인 개선 효과
- 테스트 코드를 통해서 디자인 상의 결점을 꽤 자주 발견
학습 동기부여
개발 생산성 향상
- 버그를 추적하는 시간이 현저하게 줄어들어요.
- 테스트 안 해서 아낀 시간 <= 테스트 안 해서 나온 버그 고치는 시간
프로젝트 생산성 향상
- 비즈니스 로직의 허점을 사전에 발견하기도 해요
집중력 향상
- 동시에 한 가지 이상의 일을 하지 않도록 통제해준다.

TDD를 진행하면서 실수는?

테스트 대상 오류
- 비즈니스와 관련된 버그를 낼 가능성이 낮거나 없고,
- 테스트를 유지함으로써 얻는 이익 < 테스트 유지와 관리에 드는 비용일 때
- 테스트가 단언하고 있는 내용이 사용자에게 중요한 가치를 주는 것이 아닐때는 작성하지 않는다.
검증력이 떨어지는 테스트
- 잘못된 검증.
- 차라리 안하는게 낫다.
테스트를 앞서가는 프로덕션 코드
- 앞서나가는 코드를 작성하게 되면 빈틈이 생기게 된다.
- 빈틈을 통해 버그가 발생할 수 있는 가능성.
함수가 곳곳에 퍼지게 된다.
- 낮은 결합도는 얻었지만 높은 응집력은 얻지 못했다.

무엇을 검증할 것인가?

비즈니스 가치를 주는 부분을 테스트 하자.
테스트 코드도 코드. 개선하고 유지보수한다.

후기

비슷한 경험도 했고 테스트를 작성하기에 앞서 비즈니스 가치를 주는 지 확인하는 작업도 필요해 보인다.

테스트를 돌보기 위한 간단한 실천 방법, 효과 - 양완수님

귀찮은 것.
고통스럽게 하는 것.
- 숨겨진 본질
- 테스트 욕심쟁이
  - 테스트가 실패하는 이유는 단 하나
  - 하나의 테스트는 오직 한 가지만 똑바로 검사해야 한다.
- 무엇을 테스트하는지? 인지능력의 과부화
  - 흩어진 코드와 데이터
  - 매직넘버
- 테스트가 깨지기 쉬운 것들
  - 높은 결합
  - 낮은 응집
추상이란?
- 문맥(Context) 위에서 오직 관심 있는 것들에 대해서만 집중하여 명확하게 하는 것.
숨겨진 본질
- 낮은 추상화
- 들쭉날쭉한 추상화
- 끊어진 논리
- 알 수 없는 의도

Reference

https://github.com/yangwansu/okkycon2018

후기

테스트 코드도 프로덕션 코드처럼 개선해나가는 모습이 인상적이였다.

당신의 TDD가 항상 실패하는 이유 - 이규원님

우리가 제어할 수 없는 것

외부 세상
- 현실 세계
- 인프라
- 외부 서비스
- 레거시

설계

낮은 결합
높은 응집
도메인 모델 보호
정보 숨김(information hiding)
- 어려운 설계 결정과 변경될 가능성이 높은 설계 결정들을 다른 모듈로부터 숨기는 것.
- 인터페이스 테스트
반복 주기
- 계획
- 실행
- 평가
공유하는 문화
- 목표
- 지식
도메인 모델과 플랫폼
- 도메인 모델은 플랫폼에 독립적이어야 한다.

단위 테스트는 통과되지만 항상 안전할까?

항상 안전하지 않기에 통합 테스트도 필요하다.
- 메뉴얼 테스트
- 기능 테스트
외부 연동 테스트인 경우?
- Fake Service를 만들어서 진행

후기

단위 테스트로는 발견할 수 없는 부분도 있는 실제 사례를 직접보게 되어 기쁘다.
- 사내에서도 통합 테스트의 필요성에 대해 조언을 많이 해주셨다.

Q & A

왜 TDD가 필요한가?

나를 위해서 하자.
전파하는 건 나중에 하자.
- 스스로 필요성을 느끼게 하는것이 가장 중요.
TDD 좋은 점은?
- 삶의 만족도를 높여준다.
- 빠른 피드백을 통해 직무의 탈진을 낮춰준다.
TDD는 어디서 생겼을까?
- Pair Programming을 하면서 생겼다.
- 먼저 애자일이란 환경이 갖춰줘야 한다.
  - 애자일은 사회적인 행위.
  - 나만 하는 것이 아니라 다같이 하는 행위
시간이 많이 필요합니다.
작은 변화를 일으키기 위해서는?
- 많은 도전과 실패하기
TDD를 도입하려면?
- 한번에 도입하려 하지 말고 작은 Step 진행하자.
- 한번의 하나의 실패
- 테스트의 순서가 중요.

첫 테스트를 작성할때 핵심을 테스트하자. 첫 단추부터 잘못 작성하게 되면 방향성 잃게 되어 테스트의 작성 방향이 완전 다르게 진행된다.

커버리지는 의미 있는 숫자인가?

Metric에 초점을 맞추게 되면 잃어버리는게 많다.
- 테스트의 품질도 중요하다.
- 지표를 높이기 위한 테스트는 좋지 않다.
테스트 커버리지에 초점을 맞추지 말자.

테스트하기 쉬운 코드로 개발하기 - 정진욱님

테스트하기 쉬운 코드란?

테스트 시나리오는 어떻게 작성할까?

위 테스트 시나리오 중 테스트하기 어려운 부분 어느 곳일까?

어떻게 이 문제를 해결할까?

TDD 맛보기

TDD로 code를 작성할 때 주의할 점.

두 부류 코드(테스트 하기 쉬운 코드, 테스트 하기 어려운 코드)가 만나는 Edge에서 어떻게 테스트하는가?

Mock 사용 한다는 건?

Mock의 단점은 무엇일까?

Mock을 대신하여 상태 검증를 한다는 것은?

정리하자면?

Reference

후기

의식적인 연습으로 TDD, 리팩토링 연습하기 - 박재성님

의식적인 연습이란?

의식적인 연습으로 TDD, 리팩토링 연습 과정

극단적인 Rule이라면?

의존관계 추가를 통한 난이도 높이기

Book

Question

후기

코드 품질을 위한 테스트 주도 개발 - 한성곤님

TDD란?

From Test

From Test-first

TDD Metric

후기

테알못 신입은 어떻게 테스트를 시작했을까? - 이혜승님

TDD의 좋은 점은?

TDD를 진행하면서 실수는?

무엇을 검증할 것인가?

후기

테스트를 돌보기 위한 간단한 실천 방법, 효과 - 양완수님

Reference

후기

당신의 TDD가 항상 실패하는 이유 - 이규원님

우리가 제어할 수 없는 것

설계

단위 테스트는 통과되지만 항상 안전할까?

후기

Q & A

왜 TDD가 필요한가?

커버리지는 의미 있는 숫자인가?

TDD를 배우는데 있어 도움이 되는 책들.