테스트 코드 이래도 안해?

실전 압축 TEST 근육을 위해 며칠간 밤을 세고 온몸을 비틀어가며 해보는 TEST코드를 작성했다. 온몸비틀기를 하며 배운 나의 테스트코드에 대해 느낀점을 정리하고자 한다.

---

테스트 코드

테스트 코드는 개발자가 작성한 코드가 정상적으로 동작하는지 자동으로 검증하기 위해 작성하는 코드다. 즉, 애플리케이션의 기능들이 요구사항과 기대한 동작대로 수행되는지 확인하기 위한 코드이고, 핵심은 회기 방지를 위해서이다.

하지만 일각에서는 테스트코드를 작성하는 것에 회의적이다. 왜냐면 "테스트코드가 시간을 너무 많이 잡아먹는다.", "작성을 하더라도 효과를 보지 못한다.", "어짜피 비즈니스 로직이 변경되면 또 짜야되는것 아니냐?" 라는 말이 나도 그말에 100퍼센트 동의했다.
하지만 LOOPERS 과제를 진행하면서 느꼈다. 내가 테스트 코드를 몰랐기 때문에 무시했구나.. 작성하는 방법을 몰랐고 이유를 정확하게 집을 수 없었기 때문이었구나 하고 말이다.

그래서 테스트 코드를 왜 작성하는데?

내가 내린 결론은 코드 변경에 대한 불안감을 어느정도 완화시켜준다는 것이다. 애초에 코드라는 것은 완벽하지 않다. 인간이 짜기때문에 아무리 훌륭한 코드여도 결함은 반드시 있기마련이다. 하지만 반대로 생각해보면 그런 훌륭한 개발자가 짜는 코드도 결함이 있는데, 테스트코드를 작성하지 않고서는 우리의 코드가 결함이 있는지 없는지 여부를 파악하기 어렵다는 것이다. 그런데도 안한다고? 독하다 독해~

테스트 코드를 알다

이번에 과정을 거치며 테스트 코드의 3가지 종류를 알게 됐다.

1. E2E 테스트 (End To End)
클라이언트로부터 요청, 응답까지 기능이 동작하는지 테스트하는 것이다.
2. 통합 테스트 (Integration Test)
내가 만든 코드 레이어에서 레이어로 잘 이어지는지 마지막에 DB까지 도달하는지를 테스트하는 것이다.
3. 단위 테스트 (Unit Test)
작은 코드 및 알고리즘을 테스트하는 것이다.

테스트 작성 방식: 탑다운 vs 바텀업
이 세가지 형태의 테스트 케이스를 바텀업, 탑다운 방식으로 테스트코드를 작성할 수 있다.

• 바텀업: 단위 → 통합 → E2E
• 탑다운: E2E → 통합 → 단위

나는 탑다운 방식을 사용했는데, 그 이유는 실무적인 측면에 있었다. API E2E테스트를 먼저 작성하고, controller에서 MockApi를 미리 만들어두면, 같은팀으로 있는 프론트엔드 개발자에게 예쁨을 받을 수 있다는 이유였다. 시간을 절약해서 팀의 효율을 추구하는 것이야말로 참 개발자의 자세가 아닐까?

테스트코드 하나만으로 개발에대한 나의 관심이 올랐다.
E2E는 어디까지 검증해야하나?
지금은 과제에서 준 체크리스트에 정해져 있는 테스트코드를 작성하면 됐지만, 어디까지 내가 검증을 해야하는지에 대한 의문도 남아있다.
내가 짠 테스트코드가 정말 실무에서 사용될 수 있을까?
정말 좋은 테스트 코드라는 것은 어떤것일까?
궁금한 것이 많아졌다.

마치며..

과정자체가 배울것도 많지만 힘들기도 하다. 그럼에도 뭔가를 배웠구나라는 이 감각을 느껴보니 너무 좋았다.

맞다..! 갑자기 FE한테 귀여움 받을수 있다는 얘기를 들으니까 이 명언이 갑자기 생각났다.

"개발자 실력은 특정 과도기에 들어서면 다 비슷비슷해진다. 하지만 팀원과의 소통과 화합은 누군가 가르쳐줄 수도 배울 수도 없다." - 개발 세미나에서 어떤 개발자분이 한 말

끝.