February 22, 2021
TDD
를 하다보니 퍼블리셔
와 개발자
가 떠올랐다.
퍼블리셔가 정적인 화면을 마크업해서 개발자에게 넘기면 개발자는 기능을 넣고 반복되는 코드를 제거하고 데이터에 따라 유동적으로 화면을 그리는데 이러한 과정이 TDD
과정중에 하나인 refactoring
과 비슷한거 같다는 생각을 했다. App
부터 만들기 시작했다. 그래서 좀 변경되는 부분이 많았는데 코드가 변경될때마다 어디서 에러가 나는지 테스트 코드가 알려줘서 빼먹은곳 없이 에러가 안나게 변경할 수 있었다.. 이래서 테스트 코드 작성하는구나.. 아마 테스트 코드가 없었더라면 앱을 띄워놓고 하나하나 기능을 재현해본 후에야 작업이 안된곳이 있다는 것을 알았을것이다..! 테스트 코드 짱짱!TDD
를 통해 만들어가면서 구조를 파악하고 그때그때 필요다고 생각되는 작업을 해나가야겠다. TDD
를 하면서 필요한 컴포넌트를 발견
하고 검증
하는 것이다.TDD
는 항상 테스트 코드를 먼저 작성하는 것이다TDD Cycle
에서는 내가 어느 단계에 있는지 인지하고 매우 빠르게 이 단계를 바꾸는것이 중요하다. 만약 너무 오래 걸리면 여러 수단을 통해 그 순간을 벗어나야 한다. 이걸 개선할 수 있을까?
라는 질문을 던지다는 점에서 중요하다. “더 나아질 수 있을까?”, “어느 부분을 나중으로 미룰까?” 등을 고민하고 기록하고 배우는 걸 매우 짧은 시간 안에 여러번 갖는 단계이다.(회고의 가장 짧은 주기 버전) TDD
의 강점은 바로 당장 작동하는 코드부터 만들어 나가면서 구조를 잡아간다는 것이다.오류가 발생하는 부분을 다 잡을 수 있고
점진적으로 구조를 개선
해나가기때문에 유연하게 대처도 가능하다. 그렇기 때문에 개발 속도도 더 빨라질 수 있다.TDD
에서 핵심
은 사용하는 쪽
에서 먼저 인터페이스
를 정의하는 것이다. 어떻게 동작하는지(사용하는지)에 대해 먼저 정의해주자. TDD
는 사용 설명서이다!TDD
는 항상 작게작게 시작해야한다. render
하는 것부터 시작하여 컴포넌트를 분리하고 기능을 넣고 상태관리를 추가하면서 점진적으로 구조를 개선해 나가자useSelector, useDispatch
를 mocking
하는 방법(jest.mock
, mockImplementation
사용)테스트 코드
가 먼저 만들어져야 한다.함수
를 호출하는 테스트를 사용할경우에는 꼭 beforeEach
안에서 jest.resetAllMocks()
를 사용하여 매번 테스트가 실행될때 함수 실행을 초기화시켜주자