TDD 잘알못을 위한 돌직구 세미나 참석 후기

OKKY 최단시간 마감 세미나!
TDD 잘알못을 위한 돌직구 세미나에 다녀왔습니다.

• 세미나 링크

발표순서는 변경되어서 박재성님이 먼저 진행하셨습니다.

가장 빨리 마감된만큼 참석을 원했지만 아쉽게 안되신 분들도 많을거라 생각합니다.
모든 내용을 다 담진 못했지만, 최대한 미참석자분들에게 공유될 수 있도록 작성했습니다.
이걸로 조금이나마 아쉬움을 달래셨으면 합니다.
그럼 발표 내용 시작하겠습니다!

1. 박재성

• Naver -> 아키에이지 -> NHN Next 에서 활동
• NEXT 종료 후 뭘할지 고민하다가 교육으로 가게 됨
  • NextStep으로 1인 교육 사업
• 자바지기 -> SLIPP 커뮤니티 운영
• 이 발표에서는 TDD와 리팩토링을 왜 해야하는지 알고 있다는 가정하에 진행
• 개발 현장을 떠난지 6년이 되어가고 있음 -> 상당수가 구라일수 있으니 주의

TDD와 리팩토링. 나는 어떻게 연습했나?

• 2000년대 초반 JUnit과의 만남
  • 해외 커뮤니티에서는 대단한 놈이라는데, 진정한 가치는 모르는 상태로 시간이 지나감
• 테스트 주도 개발 책과의 만남
  • 엄청 멋져 보임
  • TDD 기반으로 개발하면 좀 있어 보이는 개발자일것 같았음
  • 현실은 그렇지 않았음
• 리팩토링 책과의 만남
  • TDD와 리팩토링을 조합하면 내가 지향했던 아름다운 코드를 작성할 수 있을것 같은 희망을 가짐
  • 책만 보면 잘되지만, 현실은 잘되지 않았음
  • 간단한 유틸성격이 메소드만 적용해봄
• TDD에 대한 미련을 버리지 못하고 현장 프로젝트에 적용시도
  • 어느 순간 Mock 프레임워크를 활용한 테스트만 작성하고 있었음
  • 켄트백은 Mock 프레임워크 없이 TDD한다던데? 어떻게?
• 2009 ~ 2010년 어느날, 볼링 점수판과의 만남
  • 봄싹 스터디에서 미션 과제로 볼링 점수판을 깔끔한 코드로 구현하는 과제를 만남
  • 하다가 너무 재밌어서 막히면 다 지우고 새로 만들었음
  • 10년차, 개발팀장인 위치임에도 너무 재미있어 코드리뷰 전 3번, 코드리뷰 후 1번 구현해봄
  • 날리고 새로 만들때마다 구현 수준이 한단계씩 올라가는게 보임
  • Mock 프레임워크 없이 TDD를 진행할 수 있음을 하나씩 익히게 됨
• 현장과 무엇이 다른가 생각하게 됨
  • 기존에는 자바 웹 프로젝트에 바로 적용하려고 하니 문제가 됐던 것임
  • TDD/리팩토링 수련도 제대로 안된 상태에서 UI, 데이터베이스 등 외부와 심하게 의존하고 있는 프로젝트에 바로 적용하니 잘될리 없었음
• TDD와 관련해 7, 8년을 수련한 후
  • 테스트하기 쉬운 코드와 테스트하기 어려운 코드를 보는 눈이 생김
  • 테스트하기 어려운 코드를 테스트하기 쉬운 코드로 설계하는 센스가 생김
• 2012년부터 ATDD + TDD 기반으로 SLiPP 커뮤니티 개발
  • 무슨짓을 해도 괜찮은 장난감 프로젝트이기 때문에 가능
  • 셀레니움을 통해 웹 UI까지 100% 테스트 되도록 진행
  • Java -> Scala로 전환할때도 테스트 코드가 있어 점진적/안정적으로 개편 진행할 수 있었음
  • 현재는 코틀린으로 전환하고 싶지만, 바빠서 미정
  • 최근에는 셀레니움을 포기하고 다른 방법으로 테스트 진행

혹시 ATDD란 단어가 처음이시라면 백명석님의 메모 를 참고해보세요!

• 2014년 함수형 프로그래밍과의 만남
  • 컴퓨터 프로그램의 구조와 해석으로 Scheme (LISP계열의 함수형 언어)과의 만남
  • 함수형 프로그래밍 스타일을 자바에 적용해 구현하니 좀더 테스트하기 쉬운 코드를 구현하는 경험을 하게 됨
• 2012년 ~ 현재
  • 교육을 하고 있다보니 다양한 예제를 TDD로 구현, 리팩토링 진행
  • 볼링 점수판의 경우 지금까지 10번 이상 구현
  • 잘하고 싶은게 있다면, 반복해서/꾸준히하는 것이 중요
• TDD, 리팩토링 멋져 보인다.
  • 하지만 생각만큼 쉽게 연습할 수 있는 녀석이 아니다.
  • 많은 코드 (좋은 코드, 나쁜 코드 모두)를 봐야 늘 수 있음

추천하는 연습 방법

만약 내가 다시 주니어로 돌아간다면 어떻게 연습할 것인지

• 1단계 - xUnit 사용법과 단위 테스트 연습
  • 유틸성 메소드에서 시작
  • 알고리즘 연습할 때 적용해도 좋음
  • JDK와 같이 누군가 제공하는 API 사용법을 익히기 위한 학습 테스트
• 2단계 - TDD 연습
  • 요구 사항이 명확한 프로그램
  • 의존관계 (모바일 UI, 웹 UI, 데이터베이스)가 없는 예제로 연습
  • 로또, 사다리타기, 볼링 점수판, 체스 등 게임류
• 3단계 - 리팩토링과 객체지향 설계 (또는 함수형 프로그래밍)
  • 같은 요구사항을 반복해서 연습
  • 연습할때마다 제약 사항을 추가해 난이도를 높이면서 연습
  • 객체지향 설계 1단계 제약 사항
    • 한 메소드에 오직 한단계의 들여쓰기만 한다
    • else를 쓰지 않는다.
  • 객체지향 설계 1단계 제약 사항
    • 모든 기본형 타입은 감싼다
    • 일급 컬렉션을 쓴다
  • 리팩토링 제약 사항
    • 리팩토링 과정에서 컴파일 에러가 발생하지 않도록 한다.
  • 같은 과제를 난이도를 높여가면서 구현해야 실력이 됨
• 4단계 - 웹/모바일 프로젝트에 적용
  • 앞의 3단계와 병행
  • 처음부터 바로 현장에 적용하는건 안됨
  • 레거시에 적용하는건 진짜 난이도가 높은 기술
• 5단계 - ATDD와 CI 적용
  • ATDD (End to End 테스트)를 적용
  • CI를 통해 지속적 피드백이 가능한 환경 구축

TDD, 리팩토링 연습을 위해 필요한 것은?

• 조급함 대신 마음의 여유
• 같은 과제를 반복적으로 구현할 수 있는 인내력
  • TDD는 어느순간에선 지루하게 됨
• 나만의 장난감 프로젝트
• 가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기
• 그만큼의 값어치가 있음
  • 요즘 같이 취업 시장에 개발자가 유리한 곳이 없다고 생각

Q & A

• 컴파일 에러 없이 리팩토링 하는 이유는?
  • 설계가 크게 변하는 경우 한번에 왕창 바꾸는게 빈번
  • 한번에 너무 많은걸 바꾸려고 하다보니 2~3일 넘어가면 우선순위 높은 일이 들어오면 길을 잃게 됨
  • 작게 끊어서 점진적으로 진행하는게 연습이 되어야 함

2. <테스트하기 쉬운 코드로 개발하기> 정진욱

정진욱님의 발표는 C# 코드가 포함되어 있었습니다.
해당 코드도 함께 보시면 좀 더 문맥을 이해하시기 쉬우실것 같은데 후기를 작성하는 시점에선 아직 발표자료가 올라오지 않아서 추후에 올라오면 첨부하겠습니다.
문맥만 봐주세요!

• 나의 생일과 같이 날짜는 암기할 수 있음
• 자전거 타기
  • 외워서 될까?
  • 훈련이 필요
  • 균형 감각을 익혀야 됨
• 테스트는 암기하면 되는가?
  • 테스트는 암기가 아니라 훈련
  • 우리의 욕망은 암기에 가까움
  • 테스트 규칙을 외우려고만 함

테스트의 장애물

• 불확실성
  • 메소드 내부의 LocalDate.now()등은 상황에 따라 테스트가 깨짐
• 부수효과
  • 외부 세상의 값을 변경
  • 전역 변수
  • 로컬 머신에 존재하는 파일 내용
  • 데이터베이스의 특정 레코드
  • HTTP - POST
• 순수 함수
  • 외부 세상과 단절된 상태
  • 불확실성과 부수효과가 없는 함수를 순수함수라 함
• 리턴타입별 장애물 판별
  • 리턴 타입이 없는 경우
    • 외부 세상을 변경하는 코드가 있을 확률이 높음
    • 테스트하기 어려움
  • 리턴 타입이 있는 경우
    • 외부 세상을 변경하는 코드 존재 (출력 코드 등)
    • 이럴 경우 테스트하기 어려움
    • 만약 CQS를 지킨다면?
      • 그렇다면 테스트하기 쉬운 코드가 됨
    • 만약 CQS를 지켜도 외부세상에 의존한다면
      • 테스트하기 어려움
• 테스트하기 쉬운 코드란
  • 외부 세상(IO<T>, Future<T>)에 의존하지 않고 값을 리턴하는 경우
• IO<T>, Future<T> 를 리턴하는 메소드/함수는 테스트하기 어렵고, 반대의 경우 테스트하기 쉬움

예제 - 회원가입

• 다음은 테스트하기 쉬운 코드인지?
  • 이메일 검사, 비밀번호 검사하는 회원 가입 로직
  • 이메일과 패스워드가 유효한 경우 항상 DB를 거치는 테스트를 수행해야 함
• 어떻게 비용을 낮출 수 있을까?
• 테스트 하기 쉬운 코드로 개발하기
  • 테스트 하기 쉬운 코드와 힘든 코드를 최대한 분리하기
  • 회원 가입 코드는 쉬운 코드와 힘든 코드를 함께 갖고 있음
  • 이메일, 패스워드 체크와 DB에 등록하는 (가입) 코드를 분리
  • 이메일 클래스, 패스워드 클래스로 각각 생성해서 진행
  • 단, 이를 구현하려면 결국 분리된 이 둘이 어디선가 만나야 함
  • 이 둘이 합치는 위치는 어디가 좋을까?
    • 메소드 콜 트리의 가장 마지막 위치에서 만나게 되면 모든 상위 메소드가 다 테스트하기 어려워짐
    • 그래서 최대한 가장 바깥쪽에서 둘이 만나야 함 == Boundary Layer
  • 테스트하기 쉬운 코드와 어려운 코드는 Boundary Layer에서 만나야 한다.
    • UI 프로그램의 이벤트 핸들러
    • 웹 API의 액션 메소드
    • 즉, 내가 작성한 코드가 처음 실행되는 곳
    • 회원가입이라면 Controller 에서 둘이 만나야 함
    • 이 둘이 만나는 테스트는 인수 테스트 (전체를 관통하는 테스트)로 진행

Boundary Layer를 테스트 하는 방법은?

• DI를 통해 Mock / Spy로 단위 테스트
• 수동 테스트
• 인수 테스트
• 단위 테스트

정리 - 테스트하기 쉬운 코드 작성 방법

1. 테스트 하기 쉬운 코드와 어려운 코드를 분리 한다.
   • 보통 테스트 하기 쉬운 코드가 도메인 모델이 됨 (단위테스트)
   • 테스트 하기 어려운 코드는 서비스 모델 (수동/인수 테스트)
2. 테스트 하기 쉬운 코드와 어려운 코드는 Boundary Layer에서 만나게 한다.
3. Boundary Layer 테스트 방법을 익힌다.

3. <테스팅과 디자인> 진행자 - 이규원

이규원님이 준비한 질문들과 신청받은 질문들로 진행되었습니다.

Q. 디자인/설계를 한마디로 하면?

정진욱

• 정리 정돈

박재성

• 추상화

이규원

• 평소에 프로그래밍 하는 일

Q. 프로그래머는 언제 디자인을 하는지?

박재성

• 딱히 정해진게 있을까?
• 프로그래밍 할때면 항상 디자인을 한다고 생각함
• 코드를 작성하면서 디자인을 같이 하기는 쉽지 않음
• 그래서 TDD를 통해 구현과 설계를 분리해서 실행가능하다고 생각함
• 디자인 자체는 프로그래밍에 항상 따라다닌다고 생각

정진욱

• 넓게보면 변수명 조차 디자인이기 때문에 항상 한다고 생각함

Q. 어떤 프로그래머가 설계자일까?

박재성

• 소통을 하다보면 구현하는 사람을 비하하는 단어로 코더라고 하고, 아키텍트를 별도로 부름
• 이 둘을 분리할수는 없음
• 프로그래밍 구현과 설계는 같이 하는거지 경력에 따라 구현/설계자를 분류하는건 잘못된 접근 방식이라고 생각함
• 프로그래머가 설계자이자 구현자가 되어야 한다고 생각

정진욱

• 설계를 어떻게 보냐에 따라 다르다고 생각함

Q. 좋은 디자인이 소프트웨어/개발자에 어떤 영향을 주는지?

정진욱

• 좋은 디자인일수록 비용이 적게 든다는 당연한 생각
• 개발자에겐 고통을 줄여줌

박재성

• 책에 있는 말을 제외하고 개발자 입장에서 보면 깨끗한 코드를 볼때마다 기분이 좋아짐
• 객체지향에 잘되있는 유지보수/확장을 할때는 프로그래밍 할때 재미가 있음
• 내가 짠 코드인데 코드가 구리면 울화통이 터짐
• 개발자의 사기진작, 동기 부여에서도 충분히 도움이 됨
• 자부심을 갖게 해줌

Q. TDD는 테스트 드리븐 디자인이라는 얘기를 듣는데 어떻게 생각하는지? 좋은 설계/디자인은 무엇인지?

박재성

• 물론 그렇게 볼 수 있다고 생각함
• TDD 과정속엔 리팩토링이 있고, 리팩토링 안에는 설계가 있다고 생각함
• 좀 더 쉽고, 좋은 코드를 작성해야만 테스트하기가 쉽기 때문에 테스트가 잘 안될때 설계에 대한 의구심 혹은 힌트를 주는 계기라고 생각함
• 좋은 설계에 대한 정답은 없다고 생각함
• 좋은 설계는 컨텍스트에 따라 달라질 수 있다고 생각함
• 테스트 가능해야만 좋은 설계라고 생각하진 않음
• 현재 도메인 내에서의 최선의 설계를 찾는게 중요하다 생각함

정진욱

• 경험상으로 테스트 하기는 쉬운데 디자인이 구린 코드를 굉장히 많이 봄
• 좋은 디자인을 이루는 요소가 100개라면 테스트는 그중 1정도 되지 않을까 생각함
• 테스트가 원하는 디자인만 만족하면 테스트는 잘 돌아간다.
• 단, 테스트를 먼저 하게 되니 요구 사항에 대해 먼저 생각/고려하게 되니 좀 도움이 된다고 생각함
• 테스트는 외부에 의존하지만 않으면 하기 쉽다고 생각함

Q. 우리나라 소프트웨어 업계의 전반적인 설계에 대한 인식이 어떻다고 생각하는지?

박재성

• 많은 사람들이 중요하다고 얘기함
• 사실 말만 앞서는 경우를 많이 봄
• 우리나라의 과거의 SI 시장 영향이 크다고 봄
• 많은 관리자/고객들이 SI 생각에서 벗어나지 못했다고 생각함
• 책이나 기사를 통해 많이들 얘기는 듣지만 실제 사례가 잘 나오지 않아서 그런것 같음

정진욱

• 개발자로서 경력이 짧아 업계에 대한 이야기를 하기엔 무리가 있다고 생각함
• 시간이 급하니 정리정돈이 후 순위로 밀리는 경우와 비슷하다고 생각함

Q. 우리나라 소프트웨어 업계의 전반적인 테스트에 대한 인식이 어떻다고 생각하는지?

정진욱

• 테스트를 작성하는 사람 입장에서 테스트는 제품의 일부라고 생각함
• 근데 국내에선 테스트는 제품에 포함하지 않는 것 같음

박재성

• 거의 비슷한 의견
• 테스트가 효과를 보려면 시니어/관리자들이 테스트/클린 코드에 대한 긍정적 경험을 받은적이 있어야 함
• 운동이 좋은줄 아는 사람들은 많지만, 매일 하는 사람은 없음
• 테스트도 마찬가지로 중요함을 알지만, 가슴으로 느끼지 않는 이상 끝까지 밀고나가기 쉽지 않음

Q. 테스트가 비지니스에 어떤 도움이 되는지?

정진욱

• 안정감과 자신감
• 만약 테스트 커버리지가 100% 라면 비지니스 로직에 대한 이해도가 조금 떨어지더라도 조금만 잘못이 있어도 바로 테스트가 깨지기 때문에 위험부담이 적음

박재성

• 모보험회사에서 TDD와 리팩토링 코칭을 제안이 왔다는 이야기를 들음
• 더이상 사람의 힘으로는 비지니스적으로 유지하는데 한계가 왔지 않을까 싶음

Q. 레거시 환경에서 어떻게 TDD를 해야할지? + 전혀 TDD를 안해본 상황에서 어떻게 시작할지

박재성

• 변화를 만들려면 확신이 필요함
• 일단 나부터라도 테스트 혹은 TDD를 시작
• 그 코드를 보고 누군가 영향을 받아서 나도 하고싶다고 하면 짝프로그래밍 등으로 확장 가능
• 안통하면 때려치우고 딴데가면 됨
• 조급해하면 안된다.
• 조직을 바꾸는데는 몇년이 필요할수도 있음
• 조직이 안변하더라도 나는 끝까지 가겠다는 마음으로 진행

정진욱

• 새로운 코드를 넣을 경우에만 테스트 코드를 넣는 등으로 시작해보기나
• TDD는 구현에 초점이 맞췄다면 다른 관점으로 기존에 나온 결과를 테스트 코드로 고정시켜놓고 진행해보는 것도 좋음

Q. Java에서의 TDD는 어떻게 하는지?

박재성

• 앞
• 물론 웹 프론트엔드, 모바일 UI 등 보다는 Java TDD가 쉽다고 생각함

Q. TDD가 뭔가요?

이규원

• 내가 비지니스적으로 의미있는 코드를 작성하기 전에 이게 정상적으로 작동했을 때 어떤 결과가 나오는지를 먼저 테스트 코드를 작성하고, 비지니스 코드를 작성
• 잘못작성하게 되면 실패하니 비지니스 코드를 수정하고 다시 테스트 수행
• 이 과정을 반복
• 테스트 코드가 작성되었고, 그 코드가 통과됐다면 리팩토링을 시작해도 된다는 신호가 됨
• 코드의 기본 가치는 비지니스의 요구사항을 만족하는것
• 리팩토링을 안정감있게 진행 가능

Q. TDD에 대한 오해는 어떤게 있나?

정진욱

• 가장 유명한게 TDD는 죽었다?
• 단위 테스트를 짜려고 추상화, DI를 도입하는게 맞나? 라는 의문으로 오해가 생김
• DHH가 한 말은 단위테스트를 위한 TDD가 아닌 인수테스트를 한다는 이야기

박재성

• 테스트 커버리지가 100%가 되어야 한다는 강박은 안가져도 된다고 생각함
• 테스트 코드를 유지하고 만드는것도 비용이 듬
• 내가 봤을때 로직 자체가 너무 단순하다면 단위 테스트를 건너도 된다고 생각함
• 이분법적으로 도메인 코드의 단위 테스트 코드가 꼭 있어야 한다고 주장하면 불편함

Q. 왜 간단한 코드도 테스트 짜야 하나요?

정진욱

• property base testing
• 반대 개념이 example base testing인데 우리가 흔히 얘기하는 테스트가 이 경우
• property base testing는 에를 들어 덧셈의 성질을 이용하는 테스트
• 멱등성을 테스트 한다면 property base testing이 맞다고 생각함
• 경우에 따라 둘 중 하나를 선택해야 함

Q. Mock을 쓰면서 특정 케이스에 특정 값을 미리 정하는게 의미가 있나?

박재성

• 외부에 의존하고 있는 경우 데이터베이스, 테이블 등이 모두 존재해야만 가능
• Mock을 통해서 이런 의존 문제를 해결할 수 있음
• 처음에는 이게 뭐하는 짓인가 싶기도 함
• 만약 Mock으로 테스트하는 코드가 너무 많다면 테스트 하기 쉬운 코드와 어려운 코드가 섞여있는게 아닌지 의심이 필요

정진욱

• 외부 자원 사용을 최소화 하기 위해

이규원

• 통계학에서 실험을 할때 실험자가 제어 하는 방법이 있음
• 내가 테스트 혹은 실행하고자 하는 환경을 미리 구성해놓고, 내 코드가 성공하는지를 확인
• 내가 제어하는 요인이 정해져 있어야만 실험 효과를 볼 수 있음

Q. 왜 단위 테스트를 위해 코드를 계속 쪼개야 하나요?

정진욱

• 너무 많이 클래스와 메소드를 쪼개진다면 그게 꼭 테스트 탓일까?
• 외부 자원이나 비지니스 따라 달라진다고 생각

박재성

• 강의를 위해 극단적으로 코드를 쪼개라고 강의를 진행
• 메소드를 쪼개서 전체적인 로직이 한눈에 보이는 효과를 기대
• 메소드를 계속 쪼개다 보면 private 메소드가 많이 생기는데 이 메소드 조차 전부 테스트 해야한다고는 생각 안함
• 오직 테스트를 위해 코드를 쪼개는건 아님

Q. TDD 신봉자들은 왜 꼭 테스트를 먼저 짜라고 하나

박재성

• 강한 규칙이 불편하지만, 원칙을 따라가고 원칙을 충분히 습득 한후, 나만의 원칙을 만드는게 중요하다고 생각함
• 그걸 비난 하는 사람이 있다면 무시하면 됨

정진욱

• 테스트를 먼저 작성하게 되면 요구 사항을 먼저 생각하기 때문에 크게 일이 벗어나지 않는다는 장점이 있음
• 테스트 코드는 양팔저울이라고 생각함
• 저울의 한쪽은 테스트, 다른 한쪽은 비지니스 코드로 보면 둘이 평행을 이루는 방향으로 갈수 있다고 생각함

Q. 현업에서 TDD로 인해 개발 속도가 안나오는데 비기가 있는지?

박재성

• 그런 조직에 들어가는게 제일 현실적인 조언이라고 생각함
• 힘들고 속도가 안나오는건 혼자서 해서 그럴수도 있음
• 물론 TDD/리팩토링이 조직을 바라보는 유일한 조건이라고 생각하진 않음
• 이걸 안한다고 나쁜 조직이라고 생각하진 않음
• 다만 본인이 생각하는 기준이 TDD/리팩토링이 가장 중요하다면 잦은 이직도 할수있다고 생각함
• 만약 조직이 다 좋은데 그거만 안한다면 오프라인 커뮤니티 참석 혹은 개설도 추천함

정진욱

• 일단은 테스트 하기 쉬운 코드로 분리해서 재미라도 느껴봤으면 함
• 볼링 게임류 등 IO를 의존하지 않는 코드만이라도 테스트 해보시길

이규원

• 회사 동료에게 TDD를 교육을 함
• 사내 프론트엔드 개발자는 React를 사용중
• TDD를 하라고 어마어마하게 강조하진 않음
• 코드 전반이 아닌, 꼭 필요한 코드는 떼어내서 그 코드에 대해서만 TDD를 해보라고 가르침
• 꼭 강박을 가질 필요는 없음

Q. 셀레니움 테스트의 경우 유지 비용이 큰데 어떻게 관리하는지?

박재성

• 한때 꽂혀서 많이 사용
• 하지만 더이상 사용하지는 않음
• TestRestTemplate 등으로 API, HTML까지만 테스트하고 있음

Q. 모바일 같이 컨텍스트가 이어지는 경우 어떻게 테스트하기 쉽게 고칠수 있을지?

정진욱

• MVC 패턴에서는 테스트하기 쉽지 않음
• MVP, MVVM 등으로 View가 추상화되면 조금더 테스트하기 쉬움
• UI의 테스트는 비용이 너무 커서 하지 않고 있음

Q. UI도 TDD가 필요한가요?

정진욱

• TDD가 필요하지 않은건 아니지만, 비용이 많이 든다면 고민이 필요
• View를 추상화해서 단순한 기능만 남았다면 테스트 할 대상이 적지 않을까 생각

박재성

• ATDD는 하나의 기능 단위로 UI ~ 서버까지의 기대 코드를 먼저 짜는 것
• 현업에서는 쓰지 않고, SLiPP 구현시에 적용해서 사용

이규원

• UI는 ATDD는 하지 않고, API만 ATDD를 사용

후기

정말 좋은 내용의 세미나였습니다.
같이 다녀온 회사 동료분과 집에 가는 길에 세미나 내용으로 얘기하는데 많은걸 배웠던 세미나였음을 다시 한번 느꼈습니다.
발표 후반부에 노상범님의 말씀대로 더 큰 곳에서 TDD 주제로 컨퍼런스가 열리면 꼭 와야겠다고 생각했습니다.
좋은 세미나 만들어주셔서 다시한번 감사합니다 :)