2020년 A5 감상문

A5 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다.

팀: Microprotect

발표자: 최수형

 

한 줄 소감

TDD 도입이 시급하다...

 

이번 포스팅은 발표에 대한 내용보다는 필자가 TDD에 대한 생각 변화에 더 중점을 둔 것 같다. 발표 자체가 라이브코딩으로 진행되다 보니 발표에 대한 글보다는 발표를 보면서 느꼈던 점들, 알게된 점들을 더 작성하는 것이 좋을 것 같다고 생각했습니다.

 

 

이번 발표를 보게 된 이유

2020년도 발표를 다시 찾아보면서까지 들은 이유는 발표자이신 최수형님의 2022년 발표 ‘상태관리 이 전쟁을 끝내러 왔다’라는 발표가 너무 멋있었고 요즘들어 TDD가 개발에 필요한 요소중에 하나인 것 같다는 생각이 들었기 때문이었다.

부스트캠프를 할 때부터 TDD, ‘테스트 코드 작성하세요’라는 말을 많이 들었지만, 그 때에는 UI에서 테스트 코드를 굳이 작성 해야하나? 라는 논쟁도 있었고 개발을 먼저 이어나가는 것이 중요했기 때문에 테스트코드 작성은 뒤로 미뤘었다.

하지만 이번 토이 프로젝트를 진행하기에 앞서 TDD를 적용해보자 하는 목표가 생기기도 했고 저번 기업 과제 제출에서도 테스트코드에 대한 요구가 있었기 때문에, Test Driven Development를 적용해보고자 이번 발표를 들어보았습니다.

 

TDD 개발 사이클

발표에 앞서 TDD의 개발 사이클을 보여주셨습니다. 처음에 test코드를 작성하고, test를 통과시키기 위한 최소한의 코드를 작성해보고 이것을 리팩토링, 향상 시키는 과정으로 TDD에 접근할 수 있다고 합니다.

 

TDD가 어려운 이유와 해결 방법 (관심사의 분리)

TDD가 어려운 이유는 여러가지가 있겠지만, 우선 어떤 것을 테스트 코드로 작성해야하는지 정하는 것이 어렵다고 합니다. 어떤 것을 테스트 코드로 작성할지 모르겠다면 우선, Testable한 코드를 작성하는 것이 중요하다고 합니다. Testable하게 만드는 방법은 우선 관심사의 분리를 해야한다고 합니다. 개개인의 요소가 하나만의 책임에만 관심을 가지게 하여, 각각에 맞는 테스트 코드를 작성하면 된다고 합니다.

이번 발표에서와 2022년도 발표에서 발표자님께서는 관심사의 분리를 중요하게 여기셨습니다. 그 이유는 관심사의 분리를 통해 컴포넌트가 비대해지는 것을 막아줄 수 있기 때문입니다. 컴포넌트 작성 시 여러가지 일을 하게 한다면 이 컴포넌트는 거대해질 것이고 이는 유지보수에도 악영향을 끼칠 수 있습니다. 그래서 발표자님은 관심사의 분리를 통해 컴포넌트가 비대해지는 것을 막아줄 수 있고 컴포넌트의 분리를 통해 Testable한 코드를 작성할 수 있음을 알려주고자 하신 것 같습니다.

 

todolist 라이브 코딩

발표자님은 라이브 코딩으로 발표를 진행하셨고, todolist에 대한 코드를 작성할 때 TDD를 적용하면 어떤 모습인지를 보여주셨습니다.

주의깊게 본 부분은 컴포넌트를 원래 컴포넌트와 container컴포넌트로 나눠서 작성을 했다는 것입니다. 이것은 Redux공식 문서에서 설명하고 있는 Presentational Component와 Conatiner Component 이 두 개의 컴포넌트로 나눈것이라고 합니다.

이렇게 한 가지 일을 한다고 생각했던 컴포넌트를 두 가지 일(상태값에 관여, 실제 렌더링)로 관심사 분리를 해서 한 가지일에만 책임을 지게 함으로써 테스트코드 작성을 쉽게 해주는 것 같다는 생각이 들었습니다.

 

함수작성 시 호출부를 먼저 작성

발표자님의 라이브코딩을 보면서 나와 달랐던 점은, 어떤 로직을 작성할 때 함수의 호출부를 먼저 작성한 다음에 그 함수에 대한 선언부를 작성한다는 것입니다.

개발을 할 때 함수가 필요하다고 생각이 들면 해당 함수를 끝까지 다 만든 다음에 그 함수를 호출하는 곳에 넣고 그 다음 함수가 필요하면 또 함수 작성을 다 한 다음에야 해당 함수를 호출해주는 식으로 개발을 했습니다. 이런 식으로 개발을 한다면 로직에서 다음 부분에 필요한 것이 무엇인지 잊을 가능성이 크고 순서를 놓칠 수도 있다는 생각이 들었습니다.

호출부분을 먼저 다 작성한 다음에 해당 함수의 내부 코드를 작성하게 되면 로직에 대한 순서는 이미 함수를 호출해놓은 상태이므로 잊을 수 없고, 각 함수의 선언부에만 집중을 할 수 있으니 좋을 것 같다는 생각이 들었습니다.

테스트코드를 작성할 때에도 모든 로직을 완성한 다음 테스트 코드를 작성해서 맞는지 확인하는 것이 아니라, 테스트코드를 먼저 작성한 다음 로직을 점차 만들어가면서 테스트를 통과하게 만들고 점차 고도화하는 것이 TDD 개발 CYCLE의 완성이라는 생각이 들었습니다.

 

 

발표를 들으면서 TDD를 어떤식으로 다가가야할지 어느정도 감을 잡은 것 같아 좋았습니다. 발표자님께서 말씀하신 관심사의 분리를 통해 저도 한 번 TDD를 이번 프로젝트에 접목해보고 싶습니다!

 

 

영상 링크: https://www.youtube.com/watch?v=L1dtkLeIz-M&t=719s