Search

애플리케이션 테스트의 의의

책임의 분리

객체 지향 설계의 5가지 원칙에 해당하는 SRP(Single Responsibility Principle; 단일 책임 원칙)에 따라, 각각의 메소드와 모듈들은 한가지 기능만을 가지고 있다. 이에 따라 구현한 메소드와 모듈을 테스트 하기 위해 각각 대응하는 테스트 코드를 작성해야 한다. 이를 단위 테스팅이라 부른다.
단위 테스팅을 작성함으로써 각 메소드는 하나의 기능을 가질 수 있게 되고, 책임을 분리시킬 수 있다.

용이한 유지 보수

우리에겐 본코드 상에서의 디버깅이라는 더욱 직관적인 해결책이 있다. 하지만 애플리케이션의 요구사항이 바뀌어 기능을 부분적으로 수정해야 될 상황이라면, 긴밀하게 관계를 지어 작동하는 모듈들 사이에서 트래킹을 통해 디버깅 하기에는 무리가 있을것이다. 애플리케이션 아키텍쳐와 디자인에 대해 잘 이해하고 있어 어떠한 메소드를 수정해야 하는지 인지한다면 다행이지만, 인지하지 못한 상태로 수정이 이루어진다면 좋지 못한 결과를 맞이할 수 있다.
요구사항의 변경에 따라 달라질 수 있는 서비스 로직의 단계 별 각 단일 메소드에 대해 테스트 코드를 작성하면, 명확한 기능의 구분을 통해 유지보수하며 코드를 용이하게 수정할 수 있다.

테스트 시간 단축

개별 모듈만 테스트 할 뿐만 아니라 모든 단위 테스팅을 통합하여 전체 애플리케이션을 테스트하는데, 이를 통합 테스팅이라 부른다. 통합 테스트를 통해 유기적으로 연결된 객체와 메소드들의 메커니즘을 디버깅하며, 변경된 서비스 로직을 테스트하기 위해선 매번 전체 애플리케이션을 실행하여 메모리에 로드하며 통합 테스트를 진행해야 한다. 이는 곧 높은 메모리 사용과 시간 소요를 요한다.
서비스 로직의 각 단계마다 입력 데이터와 출력 데이터를 비교하는 테스트코드를 작성한다면, 변경된 요구사항에 따라 전체 애플리케이션을 메모리에 띄울 필요가 없어진다. 수정된 서비스 로직 레이어 또는 모듈부터 애플리케이션의 끝단까지만 실행시키며 애플리케이션을 테스트할 수 있기 때문에, 테스트에 필요한 자원을 감소시킬 수 있다.