오늘은 테스트코드 작성하는 이유를 리뷰 하겠습니다.
실제로 프로젝트를 진행하면서 개인적으로 많이 느낀 점은 테스트코드를 작성하지 않고 진행 한다면 개발할 부분이 추가되거나, 유지 및 보수를 할 때 코드에 대해서 매우 헷갈리는 경우가 많았습니다.

그래서 개발을 하면서 코드를 유지 보수 하는데에 있어 가장 바람직하고, 편리한 테스트 코드 작성에 대한 리뷰를 하려고 합니다.

테스트코드를 작성하는 이유는 다음과 같습니다.

어플리케이션 출시전의 개발과정에서 문제를 미리 발견 가능.

테스트 코드를 작성하면 비즈니스 로직을 먼저 하더라도 테스트하는 거 자체가 코드의 문제를 발견하는데 도움을 줍니다.

리팩토링을 조금 더 하기 쉬워진다.

리팩토링이란?? 코드를 알아보기 쉽고, 간단히 하는 작업, 겉으로 볼 때 결괏값은 같음.
ex) x = x + y -> x+=y
개발이 되면 추가적인 개발과 유지 보수가 필요합니다. -> 테스트 코드가 없다면 계속 메뉴얼에 따라서 동작을 검토해야 하는 부담이 생깁니다.

코드에 불필요한 내용x, 목적을 명확하게 표현하여 작성

안전성이 높아 집니다.

명세 문서로서의 기능을 수행한다

실무에서는 대부분 협업을 하여 개발하는 환경입니다.
a, b팀이 사용하는 코드 형식이 다를 수도 있어 서로 이해하기 어렵습니다.
그래서 개발자가 직접 주석을 달거나 명세를 작성하고 공유해야 하는데,
테스트 코드를 작성하면 개발하는 대상의 코드와 비교하면서 보면 이해하기 쉬워짐

테스트에는 그림과 같이 인수테스트, 시스템 테스트, 통합 테스트 ,단위 테스트가 있습니다.
이번 리뷰에서는 단위 테스트와 통합 테스트를 비교하면서 정리하겠습니다.

단위 테스트- 특정 모듈을 독립적으로 테스트

1, 가장 작은 단위 (보통- 메서드 단위)의 테스트방식
-> 메서드를 호출하여 결과값이 나오는지 확인

2, 비용이 적게 들고, 피드백을 빠르게 받기 가능

통합 테스트- 구성하는 여러 모듈을 결합하여 전체적으로 테스트

1, 외부요인 (DB, 네트워크)을 포함하여 테스트
전체적으로 온전하게 동작하는지 확인

2, 테스트를 수행할 때 모든 컴포넌트가 동작
-> 단위 테스트에 비해 비용이 커짐

※테스트 비용?
→ 금전적인 비용을 포함하여 시간, 인력 등 개발에 필요한 요소
보통 개발과정 60, 테스트과정 40 정도의 비용이 소모됨

테스트 코드 작성 방법

1, Given – When – Then

2, F.I.R.S.T

Given – When – Then

Given
테스트에 필요한 환경을 설정하는 단계, 필요한 변수, Mock 객체로 특정 상황의 행동 정의

※ Mock 객체 -테스트 작성을 위해 사용하는 거짓된 객체, 실제 객체가 아님

When
목적을 보여주는 단계, 테스트 코드를 포함하여 테스트하고 결과 값을 가짐

Then
결과를 검증하는 단계, 이 단계에서 결과 값을 검증,
결과 값이 아니어도 테스트를 하여 검증한 것이 있으면 같이 검증

F.I.R.S.T

빠르게(Fast)

테스트는 빠르게 수행돼야 한다. 테스트가 느리면 코드를 개선하는 작업이 느려져 코드 품질이 떨어질 수 있다

테스트 속도에 절대적인 기준은 없지만 목적을 단순하게 설정해서 작성하거나 외부 환경을 사용하지 않는 단위 테스트를 작성하는 것 등을 빠른 테스트라고 할 수 있다.

고립된, 독립적(Isolated)

하나의 테스트 코드는 목적으로 여기는 하나의 대상에 대해서 만 수행되어야 한다

만약 하나의 테스트가 다른 테스트 코드와 상호작용 하거나 관리할 수 없는 외부 소스를 사용하게 되면 외부 요인으로 인해 테스트가 수행되지 않을 수 있다

반복 가능한(Repeatable)

테스트는 어떤 환경에서도 반복 가능하도록 작성해야 한다 이 의미는 앞의 Isolated 규칙과 비슷한 의미를 갖고 있다

테스트는 개발 환경의 변화나 네트워크의 연결 여부와 상관없이 수행되어야 한다

자가 검증(Self-Validating)

테스트는 그 자체 만으로도 테스트 검증이 완료돼야 한다 테스트가 성공했는지 실패했는지 확인할 수 있는 코드를 함께 작성해야 한다

만약 결과값과 기댓값을 비교하는 작업을 코드가 아니라 개발자가 직접 확인하고 있다면 좋지 못한 테스트 코드다

적시에(Timely)

테스트 코드는 테스트하려는 애플리케이션 코드를 구현하기 전에 완성되어야 한다

너무 늦게 작성된 테스트 코드는 정상적인 역할을 수행하기 어려울 수 있다

또한 테스트 코드로 인해 발견된 문제를 해결하기 위해 소모되는 개발 비용도 커지기 쉽다