Test 코드를 작성하는 이유?
테스트 코드를 작성하는 이유는 다음과 같다
1. 버그를 조기에 발견할 수 있다.
테스트 코드를 통해 개발 초기 단계에서 코드의 오류를 발견 할 수 있다 이는 배포 이후에 발생할 수 있는 큰 문제를 미리 방지하는 효과가 있다.
2. 안정성 보장
테스트 코드가 존재하면, 코드 수정이나 새로운 기능을 추가 할 때 기존 기능이 잘 작동하는지 빠르게 확인 할 수 있다. 이를 통해서 의도치 않은 문제나 버그가 생기지 않았는지 검증할 수 있다.
3. 유지 보수 용이성
프로젝트가 커질 수록 유지 보수가 어려워지는데 , 테스트 코드가 있으면 코드 수정 후에도 기존 기능이 정상적으로 작동하는지 자동으로 확인 할 수 있어서 유지보수가 수월해진다.
4. 리팩토링에 자신감 제공
테스트 코드가 잘 작성 되어 있다면 , 코드 리팩토링을 할 때 구현한 기능이 에러가 나는지 쉽게 검증 할 수 있다. 리팩토링 후에도 기존 테스트가 모두 통과한다면 , 기존 기능이 정상작동하는지에대해 빠르게 알 수 있다.
테스트 이론
단위 테스트(Unit Test)
- 정의 : 애플리케이션의 가장 작은 단위인 메서드 또는 클래스 수준에서 개별적으로 테스트 하는 방식.
- 목적 : 특정 코드가 기대한 대로 작동하는지 확인한다. 한번에 하나의 기능만 집중해서 테스트한다.
- 특징 : 서로 의존하지 않게 격리된 상태에서 테스트를 진행한다. 예를 들어 컨트롤러,서비스,레포지토리를 각각 따로 테스트 한다.
통합 테스트(Integration Test)
- 정의 : 여러 모듈을 함께 테스트하여 전체 시스템이 잘 동작하는지 확인하는 방식
- 목적 : 서로 다른 부분이 함께 연결 되어 올바르게 작동하는지를 검증한다.
- 특징 : 단위 테스트와 다르게 여러 부분이 연동된 상태에서 테스트한다. 예를 들어 , 컨트롤러가 호출 되면 그 내부에서 서비스,레포지토리가 잘 연결 되는지를 확인한다.
TDD(테스트 주도 개발)
- 정의 : 개발할 때 테스트 코드를 먼저 작성하고, 그 테스트를 구현시키는 방식으로 실제 코드를 작성하고 리팩토링하는 개발 기법이다.
TDD의 3단계
- 테스트 코드 작성 : 먼저 원하는 기능을 테스트 코드로 작성한다. 이때 실제 코드는 아직 없기 때문에 당연히 테스트는 실패한다.
- 실제 코드 작성 : 테스트를 통과할 수 있는 기능을 구현한다. 기능이 완성되면 테스트는 성공해야한다.
- 리팩토링 : 테스트를 통과한 코드를 가독성이나 유지보수성을 고려해 개선한다. 이 후 다시 테스트를 실행해 성공 여부를 확인한다.
TDD의 한계
-
TDD를 하면 버그가 없을까?
그 답은 NO이다.TDD가 버그를 완전히 없애주는 것은 아니기때문이다. 테스트가 존재한다고 해도 모든 상황을 테스트 할 수 없고, 복잡한 시스템에서는 예상하지 못한 문제가 여전히 발생할 수 있다. TDD는 버그를 줄일 수 있는 도구이지만 모든 문제를 해결하는 방법은 아니다.
-
TDD는 모든 개발자에게 필요할까?
그 답은 No이다.모든 프로젝트나 모든 개발자에게 TDD가 필수는 아니다. TDD는 철저한 테스트를 요구하는 복잡한 프로젝트나 안정성이 매우 중요한 시스템에서는 큰 장점이 있지만, 소규모 프로젝트나 빠르게 기능을 개발해야하는 상황에서는 오히려 시간이 더 많이 소모 될 수 있다.
TDD를 적용하면 코드 품질을 높이고 , 초기 단계에서 많은 버그를 잡을 수 있는 건 맞지만, 모든 상황에서 TDD가 적합한 것은 아니다. TDD는 개발 속도를 느리게 만들 수 있기 때문에 모든 프로젝트에서 TDD를 고집하는것은 바람직하지 않을 수 있다 생각한다.
TDD는 다음과 같은 상황에서 부담이 될 수 있다.
- 프로토타입 개발 : 빠르게 아이디어를 검증해야하는 상황에서는 TDD가 오히려 방해가 될 수 있다.
- 프로젝트 초반 : 아직 구조나 요구사항이 명확하지 않은 상태에서는 테스트 작성이 불필요할 수 있다.
F.I.R.S.T 원칙 : 좋은 테스트의 5가지 기준
- Fast : 단위 테스트는 빠르게 실행되어야한다. 느린 테스트는 개발 속도를 저하시킨다.
- Independent: 단위 테스트는 독립적이어야하며, 다른 테스트와 연관되지 않고 독립된 상태로 동작해야한다. 각 테스트는 독립적으로 실행되어야 문제가 발생했을 때 원인을 쉽게 찾을 수 있다.
- Repeatable : 단위 테스트는 어디서나, 언제 실행하든 일관된 결과를 반환해야한다. 환경이나 순서에 따라 테스트 결과가 달라지지 않도록 해야한다.
- Self-validating : 단위 테스트는 자동으로 성공/실패를 판단해야한다. 개발자가 수동으로 결과를 검증하는 것이 아니라
assert구문 등을 통해 테스트가 스스로 결과를 확인할 수 있어야한다. - Timely : 단위 테스트는 실제 코드보다 먼저 구현해야한다.(TDD일 경우에만 해당한다.)
Given-When-Then 패턴
- Given : 테스트에 필요한 초기상태를 설정한다. 필요한 변수를 정의하거나 , Mock 객체를 사용해 특정 상황을 만든다.
- When : 실제 테스트를 하는 메서드가 호출되며 테스트를 통한 결과값을 가져온다. 테스트할 행동이 여기서 일어난다.
- Then : When 단계에서 나온 결과값을 검증한다. 예상 결과와 실제 결과를 비교하여 테스트의 성공 여부를 확인한다.
