서론

이번 과제를 통해 테스트 코드에 대해서 배웠습니다. 현재는 현업에서 테스트 코드를 작성하지 않고 있어요. 그래서 테스트 코드 과제가 쉽지 않았습니다. 하지만 최근 들어 모르는 기술을 익혀야하는 상황이 많아서 그런지 테스트 코드가 그리 어렵게 느껴지지 않았습니다. 그럼에도 불구하고 아직 장벽이 있다고 느껴지지만, 이번 항해 플러스를 통해 학습하였고 실무에 적용할 수 있는 좋은 포인트를 얻었습니다.

왜 테스트 코드가 어렵게 느껴졌는지 공유하고자 합니다.

본론

테스트 코드 작성이 어려운 이유

테스트 코드를 작성하기 위해선 여러 선수 지식이 필요하다고 생각했습니다. 관심사를 분리해서 컴포넌트를 잘 쪼개 놓아야 테스트를 보다 쉽게 작성할 수 있습니다. 또한 어떤 컴포넌트를 테스트하는지,이 부분을 이렇게 테스트하고 싶은데 어떤 API를 사용하여 코드를 구현할 수 있는지를 몰랐기 때문에 어렵다고 느껴졌던 것 같습니다.

즉 정리해보면,

어떤 부분을 테스트해야하는지를 모른다.
테스트할 부분을 찾아도, 어떻게 구현해야 하는지 모른다.

첫 번째, 익숙하지 않기 때문입니다.

동료들의 테스트 코드에 대한 질문에 대한 멘토님들의 대답은 "생소해서 테스트 코드가 어렵다"였습니다.

하지만 그리 어렵지 않을 수 있습니다.

막상 테스트 코드가 어렵지 않은 이유는 패턴이 반복되기 때문입니다.

그럼 어떤 패턴이 반복되는 걸까요? 유틸함수와 컴포넌트에 대한 테스트를 생각해볼 수 있습니다.

1. 유틸 함수

함수의 인자가 들어오면, 기댓값이 반환되는지

2. 컴포넌트 단위/통합 테스트

요소(element)를 가져오고 → 사용자 이벤트가 실행되고 → 화면이 바뀌는지 → 요소가 화면에서 사라지는지 → 새로운 요소가 화면에서 추가되는지 → 요소가 이전 상태와 변경되었는지 → 요소가 화면에 노출되는지

컴포넌트의 단위/통합 테스트에 대해서 진입장벽이 높을 것으로 생각하는데, 사실상 기대하는 결괏값 패턴만 다르고, 요소를 가져온 뒤 → 사용자 이벤트가 호출되면 → 이 순서는 크게 달라지지 않습니다.

사실상 프론트엔드에서 테스트를 하는 이유는 웹에서 사용자의 인터렉션(이벤트)에 맞게 기능이 잘 실행되는지를 검증하기 때문에 패턴이 유사할 수밖에 없다고 생각됩니다.

테스트 코드의 장단점을 살펴보려고 합니다.

왜 테스트 코드가 어려운지 살펴보았으니 이번 과제를 진행하며 테스트 코드를 작성하면서 느꼈던 장단점을 작성해 보려 합니다.

장점

1. 코드를 작성하며 느끼는 안정감

2. QA의 시간을 단축하여 결과적으로 리뷰 시간 단축

현재 제가 진행하고 있는 프로젝트에는 테스트 코드를 작성하고 있지 않습니다. 만약 새로운 팀원이 생긴다고 가정하여 코드 리뷰를 한다고 생각한다면 제 코드에 문제가 없다는 것을 알기 위해선 직접 브랜치에 pull을 받아 로컬에서 테스트를 해야합니다. 나의 시간만큼이나 동료의 시간도 중요합니다.

3. 리팩토링이 가능함

테스트 코드 없이 리팩터링을 생각보다 쉽지 않다는 것을 7개월간 뼈저리게 느끼고 있습니다. 대시 보드 내에서 자산과 관련된 총합 그래프를 그려야하는 상황에서 구현은 마쳤고 하루 안에 더 기능을 탄탄히 만들고 나아가야겠다고 생각이 들어 건의하여 하루를 리팩터링할 수 있게 됐습니다. 결론적으로 해당 리퍽터링한 커밋을 롤백하여 어떤 리팩터링도 하지 못했습니다. 그 만큼 테스트 코드 없이 이전 스펙을 모두 충족하는 동일한 기능을 만드는 것을 생각보다 쉽지 않다고 생각합니다.

해당 기능에 테스트 코드를 추가하여 공유해보려고 합니다. 기대해주세요

리팩토링은 기능의 동작은 유지하되, 코드의 가독성/유지보수성을 개선하는 방법이기 때문에 테스트 코드를 작성하면 리팩토링에 대한 안정성이 올라갑니다.

내부 코드는 변경되었더라고, 요구사항이 동일하기 때문에 내가 작성한 테스트 코드는 통과해야 하기 합니다. 그래서 테스트 코드를 작성한다면, 리팩토링하면서 기능이 잘못되는 이슈를 줄여줄 수 있습니다.

하지만 단점도 존재합니다.

단점

1. 당연히 작업 시간이 늘어남

테스트 코드도 엄연히 “코드”이기 때문에 유지보수가 필요합니다. 만약 구현과 관련한 세부 사항에 테스트 코드가 의존하고 있다면,,, 더할 나위 없이 수정에 수정이 일어나겠죠. 또한 요구사항이 아예 바뀌게 된다면 구현체와 테스트 코드를 전부 수정해야 하므로 유지 보수해야 할 코드가 늘어나게 됩니다.

단점을 보완한 방법

현재 단점을 보완해본 경험이 없어 자세히 모르지만 동료 개발자를 통해 들은 바로는

테스트 코드 작성을 팀에서 규칙으로 정하여 어느 정도 위임하여 테스트 코드 작성을 빠르게 한다고 합니다. 그렇게 하면 테스트 코드의 단점을 커버할 수 있는 것이죠.

결론

과제를 하면서 느낀 것은 테스트 코드가 어렵게 느껴지는 이유는 사용해보지 않아서라고 생각합니다.

프론트엔드 개발에서는 복잡한 비즈니스 로직보다 화면 구현에 초점을 맞추기 때문에, 화면을 가상으로 그리고 가져오며 특정 로직을 검증하는 테스트 코드가 생소하게 느껴질 수밖에 없습니다.

이번 주차를 통해 테스트 코드에 대해 학습하며 실무에 적용할 것들을 더욱 찾는 시간을 가졌습니다.

항해 플러스 코스를 신청하신 분, 고민 중이신 분들이라면 꼭 코스 시작하기 이전에 테스트 코드를 미리 공부하시는 걸 추천해 드립니다.

모두 파이팅입니다.