2020 FE CONF | 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다

최수형 | 마이크로프로텍트  << 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다. >>

 

 

 

테스트 코드 작성하시나요?)

 >> 잘 안하게 되는 것 같아요.

 

왜 안하게 되는가?)

 >> 너무 힘들고 일정에 치이다보니 안 하게 된다.

 

왜 어려운가?)

 >> Testable한 코드가 아니기 때문에

 

어떻게 Testable한 코드를 작성할까?)

 >> 관심사의 분리 Separation of Concerns 를 지키자.

            *이것을 지키지 않았을 때 => 거대한 진흙 덩어리 Big Ball of Mud가 되기 쉽다.

 

 

SRP | Single Responsibility Principle

SRP는 단일 책임 원칙이라고 한다.

이게 과연 이 컴포넌트의 관심사가 맞는가, 계속 되물으면서 관심사의 분리를 이루는 것이다.

하나의 컴포넌트가 응집된 책임을 지도록 노력하면서 작게 쪼개는 연습하는 게 TDD를 원할하게 진행하는 데 핵심이다.

작게 쪼개야 의존성이 생기지 않아서 테스트를 쉽게 작성할 수 있고 => 그래야 TDD를 잘 진행할 수 있다.

 

 

 

정리

TDD는 만능이 아니다. 설계방법론도 아니다.

'지뢰 탐지기' 라고 정리할 수 있겠다.

앞에 오는 위협 신호를 주는 탐지기다.

지뢰 탐지기가 있다고 지뢰를 다 피할 수 없다. 위기를 벗어나는 방법과 지식은 따로 공부해서 쌓아야 한다.

 

TDD 하나 만으로 좋은 설계가 나온다고 할 수 없다는 것이다.

TDD를 잘 하려면 좋은 설계를 해야하고, 좋은 설계를 하려면 TDD를 잘 해야 한다.

 

 

도대체 왜 할까?

빅 덩어리 VS 스몰 덩어리

덩어리가 작을 때 수정을 쉽게할 수 있고 비용이 줄어든다.

'미래의 고통을 지금으로 가져오는 기술' 이라고 할 수 있다.

테스트 코드를 먼저 작성한다는 것은, 테스트 관련 작업만 수행한다는 건

전체 어플리케이션에 비해 작은 부분이기 때문에 고치기 쉽고 설계 개선이 쉽다.

나중에 커진 어플리케이션에서 설계를 개선하고 수정해야 하는 고통에서 미리 미래의 고통을 지금으로 가져온다는 거다.

 

TDD하다보면 좋은 점

: 요구사항을 명확하게 하는 습관을 갖게 된다.

요구사항을 명확하게 하지 않으면 테스트를 도저히 작성할 수 없기 때문에, 요구사항을 명확하게 하는 습관을 갖게 된다는 뜻이다.

 

이러한 것을 하자라고 하면 생각보다 요구사항이 명확하지 않은 상태에서 개발을 시작하게 된다.

만들다 보니 이게 아닌데? 하는 순간이 자주 찾아온다.

테스트를 작성하면서 우리가 원하는 게 뭔지 생각하게 된다.

 

 

 

느낀점

 페이스북에서 만든 테스팅라이브러리, JEST는 라이브러리가 아닌 프레임워크라고 부를 만큼 동작 매커니즘이 잘 짜여져 있다. 이 말은 곧 test를 하기 위해서는 활용되는 함수, 메소드들이 많다는 것이고 그것을 잘 익혀야 한다는 뜻이다. 수십개의 상황에서 Boolean값을 얻어야 할지, toBe Matcher를 쓸지 등을 판단해야 하고 그러기 위해서 Jest가 가지고 있는 함수와 메소드를 파악하고 있어야 한다.

 코드를 작성하기도 바쁜 상황 가운데서 Jest 라이브러리의 메소드를 익히고 테스트를 설계하기란 결코 쉬운 일이 아니다. 자기계발을 위해 사용해볼까 하다가도 망설이게 될 것이다.

 

 하지만 TDD가 가지고 있는 분명한 이점은 있다. 요구사항을 명확하게 하는 습관을 가지게 된다는 점은 곧 세분화된 설계를 가능하게 하며 이는 SRP가 가능하도록 한다. 잘 짜여진 Clean Code를 작성하는 연습을 하고 싶다면 TDD를 하는 습관을 들이는 것이 좋다고 여겨진다.

 

 

 

동영상 원본

www.youtube.com/watch?v=L1dtkLeIz-M