단위 테스트와 통합 테스트에 대하여

출처 : 나노 바나나

최근에 인프런에서 프론트엔드 테스트에 대한 강의를 들으면서 생각한 내용을 주절주절 적어보려고 한다.

프론트엔드에서 테스트가 필요한지? 에 대해서는 과거에는 논쟁이 있었던 것으로 기억한다. 누군가는 필요하다, 누군가는 필요하지 않다.

내가 이전에 다니던 회사는 프론트엔드 테스트 코드가 없었고, 지금 회사는 있다. 하지만 테스트 코드가 있다고 크게 더 나은 점이 있는지는 잘 모르겠다. 가끔씩 프론트엔드 측에서 코드만 수정했을 때 테스트를 수정해 주지 않아서 테스트 CI가 깨지는 일이 몇 번 있었는데 오히려 번거롭다는 생각이 들 때도 있었던 것 같다.

그런데 이번에 강의를 들으면서 프론트엔드에서도 테스트 코드가 필요하다 는 생각이 강하게 들었다. 어떠한 이유들로 테스트 코드의 필요성에 대해 느끼게 되었는지 이번 글에서는 이야기를 해 보려고 한다.

단위 테스트 (Unit Test)

단위 테스트에 대한 정의는 다음과 같다.

앱에서 테스트 가능한 가장 작은 소프트웨어(단일 함수, 단일 컴포넌트)를 실행해 예상대로 동작하는지(결괏값 또는 상태) 확인하는 테스트

우리가 Textfield를 만든다고 가정해보자. 간단한 컴포넌트이지만 생각보다 신경 써야 할 영역들이 많다.

출처 : https://designsystem.line.me/LDSG/components/inputs/text-input-en

라벨, 필수 여부, 패딩, 좌우 아이콘, 플레이스 홀더, 헬퍼 텍스트 등등 UI적인 요소 뿐만 아니라 클릭 했을 때, 강조(focus)되었을 때, 마우스 커서를 올려 놓았을 때, 엔터 키를 눌렀을 때 등 이벤트 처리에 대해서도 고려할 부분이 많다.

이걸 문서화 해놓자니 너무 번거롭고 또 요구사항이 바뀌면 문서까지 수정해 주어야 하니 일을 두 번씩 하게 된다. 그리고 여러 개발자들과 함께 일을 하는 경우 서로 생각이 다를 수도 있고, 사람이다보니 빼먹고 구현을 못할 수도 있다.

만약 우리가 이런 Textfield 하나를 만들 때에도 필요한 모든 요소와 이벤트 등에 대해서 테스트 코드를 작성해 놓았다면 어땠을까? 물론 처음에 이 디자인 시스템을 만들 때는 좀 힘들었겠지만, 이후에 Textfield 관련된 버그나 요구사항 누락 등에 대해서 커뮤니케이션을 할 일은 훨씬 줄어들었을 것이라고 장담한다. 디자이너와 개발자가 이 Textfield 하나를 만들면서 필요한 모든 요소들에 대해서 같이 고민하다 보면 이후에 이 Textfield가 쓰이는 수십, 수백여 페이지에서 하게 될 Textfield와 관련된 커뮤니케이션을 아마 미리 하게 되었을 수도 있다.

Textfield와 관련된 요구사항이 처음에 만들고 나서 추가되고 수정될 수 있다. 이 경우에도 Textfield에 이미 테스트 코드가 잘 짜여져 있고, 개발자와 디자이너가 이에 대해서 이해도가 높다면 확장 가능성을 고려해서 의사 결정을 충분히 내릴 수 있다고 생각한다. 예를 들면, 헬퍼 텍스트 자리에 유효성 검증 에러가 나타나는 경우 에러 메시지를 보여주는 요구사항이 생긴다고 했을 때 1) 기존의 헬퍼 텍스트가 있다면 가릴 것인지 2) 언제 에러 메시지를 사라지게 할 것인지 등등 헬퍼 텍스트와 관련된 추가적인 요구사항을 미리 다 생각해 볼 수 있고, 이걸 테스트 코드로 다 만들어 놓는다면 미래에 신규 입사자가 왔을 때 기존에 개발자와 디자이너가 했던 고민들에 대해 번거롭게 묻지 않아도 테스트 코드만 보고 충분히 그 컴포넌트의 명세를 이해할 수 있을 것이다.

결국은 우리가 무엇을 만들건지에 대해서 더 정확하고 엄밀하게 이해할 수 있다는 점에서 테스트 코드를 짜는 것이 매우 중요하고 꼭 필요하다.

Arrange - Act - Assert (AAA) 패턴

단위 테스트를 작성하는 패턴 중에서 대표적인 것이 바로 AAA 패턴이다.

1. Arrange : 테스트를 위한 환경을 준비하기
2. Act : 테스트 할 동작을 발생시키기
3. Assert : 올바른 동작이 실행되었는지 검증하기, 변경사항이 제대로 바뀌었는지 검증하기

사실 우리는 이러한 패턴을 개발하면서 이미 쓰고 있다. PRD라고 하는 기획 문서에서 ~~~ 한 상황에서 ~~~ 을 실행하면 ~~~ 한 결과가 나타난다. 이런 식으로 말이다. 테스트 코드는 이러한 PRD 문서를 코드로 옮겨놓은 형태라고 생각한다.

만약에 개발된 결과물이 PRD와 다르면 보통은 버그라고 생각하는 경우가 맞다. 하지만 이게 버그일 수도 있지만, PRD에 명시되지 않은 경우일 가능성도 있다. 기획자도 사람이라 어떤 경우는 PRD가 틀릴 수도 있다. 기획자의 입장에서는 PRD의 문서 대로 결과물이 제대로 구현이 되어 있는지 항상 신경을 쓸 수 밖에 없는데, 테스트 코드가 잘 짜여져 있으면 지속적으로 기능이 추가되더라도 기존의 기능들이 PRD 대로 문제 없이 동작함을 보장할 수 있기 때문에 기획자도 신경을 덜 쓸 수가 있다.

모든 테스트는 독립적으로 실행이 되어야 한다. 순서가 바뀐다고 테스트 결과가 바뀌면 그것은 좋은 테스트라고 볼 수 없다. 그래서 테스트 전과 후에는 일관성을 보장하기 위하여 setup, teardown이라는 단계를 넣어 준다.

• setup : 테스트를 실행하기 전 수행해야 하는 작업 (e.g. beforeEach, beforeAll)
• teardown : 테스트를 실행한 뒤 수행해야 하는 작업 (e.g. afterEach, afterAll)

ㅇㅇ

d출처: 나노 바나나