클린 코드와 TDD 특강 정리

우테코 박재성(Jason)님의 특강이였다.

개인적으로 라이브 코딩을 통해 강의해주신 부분이, 어떤 플로우로 테스트 코드를 작성하면 좋을지를 파악하는데 너무 좋아서 만족했던 강의였다.

최고!

테스트

• 남들에게 실행 시키기 전에 수동 테스트 해봤던 경험이 있을 것
  • 내가 원하는 방식으로 작동이 되는지 확인하기 위해 
  •  

테스트의 진화

언어별, 국가별, 장치별 테스트를 모두 수동으로 할 수 있을까?

• QA 조직의 등장테스트

자동화된 테스트

• 자동화된 테스트의 필요성은 사람에 따라 다를 수 있음
  • 못 느낄 수도
• 버그를 잡는 것은 테스트 해야 하는 많은 이유 중 하나일 뿐 소프트웨어의 변화를 지원하는 역할이란 것을 이해하자
  • 네카라 같은 기업들은 지속적으로 코드를 개선한다
  • 자동화된 테스트는 실수를 발견해주고 자신있게 코드를 작성하는 것에 도움을 준다

개발자 주도 테스트의 장점

• 디버깅 감소
• 자신있게 변경
• 더 나은 문서 자료
• 더 단순한 리뷰
• 사려 깊은 설계
• 고품질의 릴리스를 빠르게

다시 테스트를 정의해보자.

테스트는 팀원들의 집단 지성을 팀 전체의 이익으로 환원하는 방법이다.

발목을 잡는 테스트

테스트를 작성하는 것과 좋은 테스트를 작성하는 것은 별개의 문제

• 테스트 코드도 코드.
• 개발자도 사용자라고 가정한다면 테스트 코드도 코드
  • 즉 지속적으로 관리해야 함
• 테스트는 엔지니어에게 신뢰를 줄 때만 가치가 있다.

테스트 피라미드

이 그림이 의미하는 것은 무엇일까

• GUI를 통해 실행되는 높은 수준의 E2E 테스트보다 낮은 수준의 단위 테스트가 더 많아야 함을 의미한다.
• 70-20-10 또는 80-15-5
  • 유닛-서비스-UI의 비율

정확성 피라미드

• 개발 주기 후반에 버그를 발견할수록 수정하는데 더 큰 비용
• 테스트를 작성하지 않는다는 것은 정적 타입 지정 언어가 아닌 동적 타입 지정 언어를 사용하겠다는 것과 같음
  • 정적 타입 언어를 사용할수록 컴파일단에서 에러를 찾을 수 있음

TDD

테스트 주도 개발

매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나

• 흔히들 TDD 는 테스트 코드를 먼저 작성하는 것! 이라고 생각하지만 사실은 TFD + 리팩토링

TDD 작성 순서

빨간색 - 실패하는 작은 테스트를 작성한다.

초록 - 빨리 테스트가 통과하게끔 한다. (오로지 통과만하면 된다. 무조건 특정 상수만 반환되게 또는 다른 죄악을 저질러도 된다)

리팩터링 - 초록 과정 중에 생겨난 모든 중복과 죄악을 개선한다.

• 초록 상태의 코드를 작성 해놓고 프로덕션 코드(사용자에게 전달될 코드)가 작성되면 끝?
  • ㄴㄴ 굉장히 더럽다.
  • 리팩토링이 필요함
    • 그렇다면 리팩토링이란?
      • 인풋과 아웃풋을 고정한 상태에서 내부 코드를 변경

그렇다면 TDD가 주는 것: 용기

테스트 주도 개발은 프로그래밍을 하면서 나타나는 두려움을 관리하는 방법

• 불확실한 상태로 있는 대신 가능하면 재빨리 구체적인 학습을 하기 시작
• 침묵을 지키는 대신, 조금 더 분명하게 커뮤니케이션
• 피드백을 회피하는 대신 도움이 되고 구체적인 피드백을 찾음
  • 빠른 피드백

TDD를 어떻게 학습할 것인가

• 강사님도 5-6년 후에야 테스트하기 쉬운/어려운 코드를 구분하고 쉬운 코드로 설계하는 안목을 기름

그렇다면 어떻게 해야할까?

목적의식이 있는 연습에 얼마나 많은 시간을 투자했는가?

• 지속적으로 현재 능력을 살짝 넘어가는 작업을 시도
• 명확하고 구체적인 목표를 가지고 진행
  • TDD에서는 테스트를 통과시키는 것
• 의식적인 연습이 중요

TDD도 도구다

• 목적에 맞게 이용
• 단위 테스트에서 점차 늘려나는 것
  • 인수 테스트에도 적용해보고!
  • 그렇게 하다보면 활용 단계에 도달할 수 있다

자동차 경주 예시

기능 요구사항

이 주어졌을 때 개발을 하려면? → 막막

먼저 요구사항 분석과 설계가 필요

요구사항 분석 및 설계

• 요구사항 분석을 통해 대략적인 설계
• UI, DB등에 의존하지 않는 부분
  • ex, MVC에서는 뷰와 컨트롤러 의존관계이기 때문에 도메인만 설계한다던지!

1. 객체 설계

먼저 자동차가 필요

→ 차가 여러대 필요

→ 레이싱 게임이라는 것이 필요까지 도출하자.

2. 기능 목록 추출

기능 목록 작성하는 것도 역량 필요?? → 역량도 중요하지만 연습이 필요함

아무튼 일단 구현하자!

테스트 하기 어려운 부분을 찾아 가능한 구조로 개선

• 객체 그래프에서
  • 객체 그래프: 객체가 객체를 도는 함수가 함수를 호출하는 것
• 테스트 하기 어려운 코드의 의존관계를 객체 그래프의 상위로 이동
  • Random을 위로 올리기
    • 이러면 RacingGame
    • 한번 더 올리기

테스트 하기 어려운 코드

• 랜덤, 날짜, shuffle

외부 세계

• 외부 Rest API
• DB

구현한 모든 코드를 버린다.

테스트 가능한 구조로 만들기 어려운 상태까지 연습하고 모든 코드를 버린다.

• 이렇게 앞 단계 구현을 통해 도메인 지식을 쌓을 수 있다.
• 구현할 기능 목록 작성 또는 간단한 도메인 설계
• 만만한 것부터 다시 구현

결론!

이렇게 지속적으로 반복하면서 좋은 코드에 대한 본인의 기준을 세우는 것이 중요하다.

또한 클린 코드란 뭘까?

클린 코드란 내가 읽기 좋은 코드, 팀 프로젝트라면 팀원들이 읽기 좋은 코드이다.

본인의 기준을 세우고 그에 맞는 클린코드를 작성하기 위해 노력하자.