TDD Clean Code with JavaScript 4기- 1주차

Eamon·2022년 11월 3일

NEXTSTEP TDD Clean Code with JavaScript 4기

nextstep 에서 진행하는 TDD Clean Code with JavaScript 4기 강의를 듣고 정리한 내용입니다.

OT

강의 목표

js 를 “잘 사용하는” 코드를 작성하기 위한 수업
“의식적으로” 더 잘 사용할 수 있을까? 를 고민
읽기 좋은 코드를 보는 것이 왜 좋은 것인지 느끼는 과정 → 1:1 코드리뷰 잘 활용
TDD 와 test

강의 커리 큘럼(8주차)

1 .계산기 : cypress 를 이용하여 E2E 테스트 작성하고 개발하는 경험
2. 로또 : UI 와 도메인 영역 분리하여 테스트
1. 자동차 경주
2. 자판기

슬기롭게 2달을 보낼 수 있는 방법

리뷰어를 하기 위해서 끝까지 참여를 한다.
현석님과 메이커준님 + 리뷰어님에게 적극적인 질문을 한다.
미션을 위한 모각코, 같이 공부한다.
리팩터링을 통해서 Before & After가 기록되어 역량을 보여주기 위한 포트폴리오가 될 수있다.
수강료를 생각하여 집중하자..ㅎ (0.5 M1 맥북)

채팅 채널 적극적 이용해보자

TDD(Test Driven Development) 란?

켄트백이 TDD에서 강조한 것은 “사고 방식”

결정과 피드백사이의 갭에 대한 인식
더 나아가 결정과 피드백 사이의 갭을 조절하기 위한 테크닉
빠른 피드백을 받을 수 있는 방법

농구공을 던졌는데 그 공이 들어갔는지 한 달 뒤에 들어갔다고 생각하면 답답하다. 당장 바로 공이 들어갔는지 안들어갔는지 알게 되는게 좋다.

“테스트 코드가 본질을 아니다.”

빠른 피드백은 받는것이 본질

의도치 않은 유용한 “부산물”

TDD 언제할까?

처음 만들어보기 때문에 막연하거나 요구사항이 “변경가능성이 높고” 개발과정에 “코드가 변경이 많이” 될 경우
유지보수를 내가 아닌 다른 사람이 해야할 경우

QnA

Q. 피드백은 보통 누구에게 받는가요?
A. 자동화된 컴퓨터.

Q. TDD를 하면서 개발속도가 빨라질 수 있나요??
A. 불확실성이 높은 상황일 수록 TDD로 개발할 때 빠르게 작성할 수 있다.

Q. E2E 테스트는 유닛테스트에 비해 피드백 주기가 길 것 같은데 싸이프레스로도 유닛테스트가 가능한가요?
A.가능하다. E2E 테스트를 작은 단위로 어떻게 하면 만들 수 있을지 다음 강의 때 같이 고민해보자

계산기에 TDD 적용하기

내가 해결할 수 있는 가장 작은 영역의 문제부터 풀어나가고 피드백 받기(단, 핵심을 포함하게!)

계산기의 핵심은 무엇일까? → 계산하기 → 동작하기 위한 최소한의 기능은 “2개의 숫자를 다루는 계산기”

UI 없이 사칙 연산이 되는 것만 먼저 빠르게 만들기
input 으로 사용자 입력 받고 이벤트 처리하기 (버튼이 아니라) → 최소한의 Ui 로 최소한의 기능을 추가
숫자 UI 추가하고 이벤트 처리하기

best practice라는 결과보다 best practice 로 가는 과정을 느꼈으면 좋겠다.

클린 코드 보다는 클리닝 과정을

“의도가 드러나는 네이밍” → 어려운게 당연하다. → “어떤 과정을 거치면 좋은 네이밍이 나타날까?” 를 중점으로 생각한다.

워드 커닝햄의 네이밍

의도를 다 들어내라 ( 길어도 )
구현을 숨겨본다.
반환타입에 대한 힌트를 넣는다.

example)

linearSearchFor: -- indicates how the method works
searchFor: -- 구현을 숨긴다.
includes: -- is even better ( 리턴타입이 boolean )
getLinearSearchPosition: -- indicates how the method works
getPosition: -- 구현을 숨긴다.
indexOf: --( 리턴타입이 idx : number )

TDDing

어떤 과정을 거쳐서 Test 를 작성해야 작게 쪼갤 수 있을까?

Think about what you want to do.

하고 싶은 일을 생각해 보세요.

Think about how to test it.

테스트하는 방법에 대해 생각해보세요

Write a small test. Think about the desired API.

작은 테스트를 작성하면서 원하는 api를 생각해보세요

Write just enough code to fail the test.

테스트에 실패할 만큼만 코드를 작성하세요.

Run and watch the test fail. (The test-runner, if you're using something like JUnit, shows the "Red Bar"). Now you know that your test is going to be executed.

실행하고 테스트가 실패하는지 확인하세요.

Write just enough code to pass the test (and pass all your previous tests).

테스트를 통과할 만큼의 코드만 작성하세요.

Run and watch all of the tests pass. (The test-runner, if you're using JUnit, etc., shows the "Green Bar"). If it doesn't pass, you did something wrong, fix it now since it's got to be something you just wrote.

실행하고 모든 테스트가 통과하는지 확인하세요.이 때 통과하지 못하면 뭔가 잘못한 것인데, 방금 작성한 부분을 수정하세요.

If you have any duplicate logic, or inexpressive code, refactor to remove duplication and increase expressiveness -- this includes reducing coupling and increasing cohesion.

중복이 있는 경우 제거하고 재사용성을 높이기 위해 리팩토링합니다. 여기에는 결합도 감소 및 및 응집도 증가가 포함됩니다.

Run the tests again, you should still have the Green Bar. If you get the Red Bar, then you made a mistake in your refactoring. Fix it now and re-run.

테스트를 다시 실행하면 여전히 모든 테스트가 동과해야 하빈다. 빨간색 막대가 표시되면 리팩토링에 실수를 한 것입니다. 그 경우 수정하고 다시 실행해주세요

Repeat the steps above until you can't find any more tests that drive writing new code.

새 코드를 작성하는 테스트를 더 이상 찾을 수 없을 때까지 위의 단계를 반복합니다.

QnA

Q. 공유해주신 자료들과 같은것은 보통 어떤경로로 많이 찾으시나요?
A. 관심있는 엔지니어 덕질은 한다.

Q. TDD 단계에서 왜 실패하는 코드를 먼저 작성해야하나요?
A.내가 무엇에 대해 피드백 받을지를 명확하게 인지하기 위함

Q. 말씀해주신 워드 커닝행의 과정을 그대로 따라가기 보다는 나만의 방식을 먼저 찾아보는게 좋을까요?
A. 나만의 방식을 찾아나가면서 나의 상황에 맞춰보자

Q. 저 또 궁금한게 있는데 테스트를 작성한 후에 코드를 작성하라고 되어있는데 코드를 작성 후 테스트를 작성하는 것과 어떤 점이 다른가요?
A. 테스트를 먼저 작성하게 되면, 테스트를 통과하기 위한 최소한의 코드의 범주가 명확해짐
구현 코드를 먼저 작성학세 되면 피드백을 받기 까지 시간이 더 걸림

Q. TDD로 자신이 짠 코드의 100%의 커버리지를 달성하긴 어렵다고 보는데, 어느정도 범위까지의 테스트를 해야하는지 항상 고민이 될 것 같다고 생각합니다. 이것까지 테스트 해야하나? 하는 등의 의문이 찾아올 수 있다고 생각하는데.. TDD에서의 테스트 작성 범위는 어디까지가 이상적일까요?
A. 정답은 없고 내가 만드는 서비스에 따라서 테스트 커버리지가 천차만별이다.
커버리지가 100%라도 버그가 발생 할 수 있다.
커버리지가 10%라도 적절한 핵심 로직에만 테스트를 잘 쓰고 있다면 좋은 상황