[CS] 테스팅의 목적과 좋은 테스팅이란
요즘 테스트코드를 작성하는 횟수가 부쩍 많이 늘어났다.
처음에는 테스트코드를 짜는게 마냥 막막하고 어려웠는데, 지금은 금방금방 만들어내고 있다.
그런데 나 혹시 지금 좋은테스팅을 하고 있는게 맞을까?
예전에 학교에서 오픈소스응용프로그래밍이라는 강의를 들은적이 있다 (개인적으로 내 인생 강의)
그 당시 교수님이 프로젝트를 팀으로 진행하도록 하면서 여러가지 협업때 해야되는 다양한 프로세스를 경험할 수 있었다. 그중 하나는 테스트코드 작성하기였다.
강의를 들으면서 그 당시에는 아 테스트코드 필요하구나… 이랬었는데, 지금 다시 하려니까 그때의 목적성이 전혀 생각이 안났다.
그래서 다시 찾아본다. 우리는 왜 테스트코드를 작성하는것일까?
🤔 테스팅의 목적
당시 저 강의를 들으면서 알게된것인데 생각보다 우리가 개발방법론이라 표현하는 애자일기법이나 테스팅들은 비용과 관련이 많다.
출처: https://www.stickyminds.com/article/shift-left-approach-software-testing
보통 프로젝트에서 오류는 대부분 코드를 작성하는 단계에서 이루어진다 한다. 만약 초기에 이 문제를 잡지 않고 넘어간다면, 이후 릴리즈 단계에서 문제를 개선하기 위해서 필요한 비용은 뒤로 미뤄질수록 기하급수적으로 증가하게 된다.
그렇지만 만약 앞에서부터 테스트를 하며 넘어갔다면
출처: https://sonseungha.tistory.com/630
이렇게나 처리 비용이 내려가게 된다.
결과론적인 얘기처럼 보일수 있지만 우리는 소프트웨어가 만들어지고 유지보수까지 생각했었을 때 테스트는 하지 않았을 때 과도하게 소모되는 비용을 줄이기 위해서 한다고 볼 수도 있다.
번외로 테스팅을 간과해서 발생했던 큰 사고가 있는데 한번 봐도 좋을것 같다.
🍯 개발자가 테스트를 통해 얻는 이득
하지만 이렇게 비용적인 점만 있는것은 아니다.
위에서 비용과 연관지은것은 좀 극단적이게 테스트 해야돼!!! 라고 말하고 싶어 들고온 것이고, 실제 개발자가 테스트를 하면서 얻을 수 있는 이득도 정말 많다.
버그 조기 발견
테스팅을 통해 코드의 결함이나 버그를 초기에 발견할 수 있도록 한다.
코드 안전성 향상
자동화된 테스트는 코드 변경 후에도 기존 기능이 정상적으로 동작하는지 확인할 수 있다. 이런 테스트 코드를 작성했다면 코드를 변경했을 때 그에 맞게 또 print("hello")를 찍지 않아도 된다.
개발 속도 향상
테스트코드를 작성하면 개발 속도가 저하할거라고 초반에 쉽게 생각할 수 있지만, 장기적인 관점에서 테스트코드는 결국 개발 속도의 향상으로 이뤄진다.
당장 프로젝트를 하며 만났던 오류를 찾아내기 위해 얼마나 많은 디버그 브레이크포인트를 찍었고, 몇번의 디버깅을 했는지 생각하면 테스트코드는 개발 속도 향상과 연관된다고 금방 알 수 있을것이다.
물론 이런 사람이라면 안짜도 될수도 ㅋㅋ
👍 좋은 테스트코드 작성하기
이렇듯 개발자로써 테스트 코드를 작성해주는것은 소프트웨어 전반적으로 긍정적인 영향이 있다.
그렇다면 이런 테스트코드 적당히 짜면 될까?
당연하지만 안된다. 우리가 좋은 SW를 만들기 위해 좋은 코드를 지속적으로 지향하고 고민하듯 테스트코드 또한 그렇다.
???: 그렇다면 테스트 커버리지를 100% 드가자 ㅋㅋㅋ
이는 물론 중요한 요소이지만 100% 커버리지를 만들려고 하지 말자. 완벽한 코드는 없고, 완벽한 테스트는 없다.
이러한 한계점에 대해 명확히 인지하고 있다면 이제 우리가 지향해야 되는것은 좋은 테스트코드를 만드는것이다. 과연 좋은 테스트코드는 무엇을 뜻하는것일까?
이러한 좋은 테스트에 대해 찾다 보면 나오는 몇가지 키워드들이 있다.
#회귀 방지#리팩토링 내성#빠른 테스팅#독립적
이 중 쉽게 이해가 되는 빠른 테스팅은 제외하고, 독립성은 리팩토링 내성과 매우 연관이 있으니 이 둘을 제외한 나머지 두가지 키워드에 집중해보자.
회귀 방지
회귀 방지라는게 무슨뜻일까? 여기서 말하는 회귀는 일종의 소프트웨어 버그이다.
우리가 프로젝트를 진행하면 규모는 점점 커지는데 만약 테스트를 작성하지 않았었다면 미래에 코드에 에러가 났을 때 이미 완성했다 생각했던 코드를 수정하러 돌아가야 된다.
좋은 테스트는 이렇게 사전에 문제상황을 방지하여 프로젝트 개발시 뒤로 되돌아가지 않도록 도움을 준다.
리팩토링 내성
테스트코드는 리팩토링을 했을 때 내성이 있어야 된다. 프로덕트의 코드는 리팩토링이 되더라도 그 기능을 테스트하는 테스트코드는 바꾸지 않고도 테스팅을 할 수 있어야된다.
소위 거짓 양성을 줄인다고 하는데, 거짓 양성이란 간단히 예를 들어 설명하자면 리팩토링을 거친 프로덕트의 기능은 모두 동일한데 테스트가 실패하는 경우를 얘기한다.
좀 더 간단하게 말하자면 맞왜틀(맞는데 왜 틀렸다함?)이다.
이러한 거짓 양성은 테스트에 대한 개발자의 인식의 변화를 일으키는데
- 하나는 테스트가 주는 신뢰성이 하락하게 되며 회귀를 방지하는게 아니라는 불신을 만들게 되고
- 다른 하나는 이유가 없이 실패를 반복하며 테스트를 신경쓰지 않고 그대로 프로덕트 릴리즈에 갈수 있다는 것이다. 이러한 문제가 발생할 수 있기에 리팩토링으로 인해 기존 테스트에서 거짓 양성을 띄게 할 수 있는 테스트코드는 좋지 않다는 것이다.
🎬 끝내며
오늘 테스트코드를 작성하다가 객체지향에도 SOLID원칙이 있듯 테스트코드에 대한 좋은 방향을 위한 원칙을 찾기위해 시작했던 것이었는데 좋은 레퍼런스도 많이 찾았고, 앞으로 내가 테스트코드를 작성해야되는 타이밍이나 이 테스트를 하기위해 또 적절한 설계를 해야된다는것도 알게 되었다.
단위 테스트 - 예스24 추가로 테스트와 관련된 좋은 책으로 이 책을 많이 소개해주시던데 한번 읽어봐야겠다 생각했다.
🔗 레퍼런스
해당 자료를 찾아보며 도움이 됐던 링크