테스트 주도 개발 패턴 (2)

빨간 막대 패턴

---

한단계 테스트

우리들인 테스트를 할 때 어떠한 방법으로 하는지 API를 개발할 때 컨트롤러부터

테스트할 때 도 있고 DAO나 Repository 먼저 테스트하는 경우도 있습니다. 켄트백은 이러한 상향식 프로그래밍

하향식 프로그래밍은 TDD 프로세스에 대해  효과적으로 설명할 수 없다고 말을 합니다. 

이와 같은 수직적 메타포는 시간에 따른 단순한 변화일 뿐이라고;; 

메타포: 본래 표현되어야 할 내용을 간접적으로 명시하는 것이다. 
예시: 인생은 여행이다. 

더닝 크루거

켄트백은 TDD에 대해 성장이라는 키워드에 초점을 맞췄다.

우리는 TDD를 처음 접할 때는 더닝 크루거 효과처럼 TDD에 아주 얕은 부분만 알고 알고있는 테스트만 작성을 합니다.

그렇게 알고 있는 테스트만 작성하게 된다면 우리는 해당 테스트가 완벽하고 작성한 코드도 완벽하다고 생각을 하게됩니다. 하지만 실제 프로덕션 코드는 테스트를 했음에도 불구하고 알 수 없는 에러가 발생하게 됩니다.

 

그렇기에 우리가 모르는 부분을 테스트하는 것이 지금은 좌절하고 자존감도 떨어 질 수 있지만 궁극적으로는 성장하는 나와 프로그램을 갖게 될 수 있습니다.

 

시작 테스트

테스트를 작성하면서 우리는 모든 경우의 수를 생각을 하고 모든 케이스를 테스트 해야된다고 생각을 합니다.

하지만 시작은 시작일 뿐입니다. 우리가 모든 케이스를 다 생각하고 처음부터 다 완벽하게 설계하고 절대 버그가 나지 않는 코드를 작성하는 것은 어렵습니다.

 

그리고 이렇게 모든 테스트 케이스를 작성해보면서 그만큼 주변에 받는 피드백도 늦어지고 피드백을 하는 사람 입장도 너무 많은 코드에 대한 리뷰를 하는 것도 부담이 됩니다. 켄트벡은 빨간막대 초록막대 패턴을 강조하였는데 일단 아무것도 하지 않는 코드라도 만들어서 시작부터 하는 것입니다.

 

설명 테스트

 

자동화된 테스트를 널리 알리고 다른 사람에게도 TDD의 중요성을 알리게 하려면 어떻게 해야될까?

일단 나더 세로운 것에 대해 열의가 넘쳐서 새로운 것을 도입해야한다고 장점을 설명하면서 설득보다 강요에 가깝게 

된 적이 많은 것 같다. 켄트백도 이걸 꿰뚫어보고 우리는 다른 사람의 일하는 방식을 함부로 바꿀 수 없다고 말한다.

 

스피드 웨건처럼 설명충이 되어 버리면서 오히려 TDD가 퍼지는 것을 더 빠르게 막아버리는 악화시켜버린 것입니다.

하지만 우리가 코드를 설명하거나 우리가 설계한 로직을 테스트 코드로 반복적으로 보여주면 어떻게 될까?

상대방 입장에서는 테스트 코드만 보고 복잡한 비지니스 로직을 쉽게 설명을 하면서 상대방은 TDD의 매력에 점점 빠지게 될 것 입니다. 

 

학습 테스트

 

처음접하는 기술 스택, API, 모듈을 사용할 때에는 낯설기 마련이다. 그렇기에 우리는 해당 프로그램이 무슨 일을 하는지에 대해 코드로 작성해보고 테스트를 성공하게 되면서 확실히 알게 되는 것이다.

 

예를 들어 아래와 같이 api에 대한 테스트 코드를 작성해보고 해당 결과값을 받아 테스트 해보면 제공받은 api가 무슨 역활을 하고 어떠한 결과 값을 가져오는 지 알 수있다.

@Test
public void 
givenRequestWithNoAcceptHeader_whenRequestIsExecuted_thenDefaultResponseContentTypeIsJson()
  throws ClientProtocolException, IOException {
 
   // Given
   String jsonMimeType = "application/json";
   HttpUriRequest request = new HttpGet( "https://api.github.com/users/eugenp" );

   // When
   HttpResponse response = HttpClientBuilder.create().build().execute( request );

   // Then
   String mimeType = ContentType.getOrDefault(response.getEntity()).getMimeType();
   assertEquals( jsonMimeType, mimeType );
}

 

회귀 테스트

시스템 장애가 생겼을 때 해당 장애로 인하여 실패하는 테스트와 통과할 경우 해당 장애가 수정해서 정상적으로 동작하는 테스트를 작성합니다. 하지만 이렇게 수정하는 과정에서 어떤 사이드 이펙트가 우리를 기다리는지 알 수 없습니다. 

이런 문제점을 해결하기 위해 하는 것이 회귀 테스트 입니다.

 

회귀테스트를 하는 방법은 여러 가지가 있습니다. 예를 들어 이전에 작성해놓은 테스트 코드를 모두 동작시켜본다거나 아니면 변경된 코드에 영향받는 부분만 테스트를 합니다. 이렇게 회귀테스트를 진행하면서 우리는 시스템 장애에 대한 테스트 코드를 격리시킬 수 없다면 잘못된 설계를 했다는 것을 느끼고 리팩토링을 진행해야 합니다.

 

테스팅 패턴

---

자식 테스트

거대한 테스트 케이스 같은 경우 어떻게 테스트를 해야할까?  켄트백은 빨간 막대, 초록 막대 패턴으로 TDD 패턴으로 개발하는 것을 중요하게 생각을 해서 자식 테스트를 만들고 자식의 자식 테스트를 만들면서 하나의 거대한 테스트를 작게 분리하면서 A테스트가 완료되면 B테스트로 완료시키는 방식으로 접근해보고 자신의 맞는 방법으로 구현하는 것을 목표로 해야 된다 설명하고 있다. 이렇게 테스트 하면서 큰 테스트 케이스에 대해 부분부분 완성 시키다보면 단일 책임 원칙을 지킬 수도 있는 개발이 되어 켄트백일 말했던 결합도는 낮고 응집도는 높은 구조의 아키텍처를 구성할 수 있을 것이다.

 

모의 객체

비용이 많이들거나 복잡한 리소스에 의존되는 객체를 테스트를 하려면 어떻게 해야될까?
예를 들어 데이터베이스와 연동하여 테스트 하려면 우리는 해당 환경을 구축하고 동일한 구조의 스키마를 유지해야합니다. 하지만 메모리에 영역에서 모의 객체를 사용하여 테스트를 작성한다면 우리는 굳이 이 로직을 테스트 하기위해 환경을 또 구축해야 되는 번거로운 일을 덜어 낼 수 있습니다. 그래서 우리는 mock 객체 같은 테스트 객체를 만들어 사용하는 것입니다.

 

주의점

• 실제 객체와 동일하게 동작해야 한다.
• 가시성을 생각하고 커플링이 감소하도록 설계해야한다.
• 싱글톤 패턴을 사용하려면 주의하여 사용해야한다. (전역 변수에 선언한다는 것은 모든 곳에 참조하고 테스트 후에 다시 되돌려놓아야 하는 번거러움이 생길 수 있습니다. 그러므로 상수만 사용하도록 합니다.)

셀프 션트

우리는 한 객체가 다른 객체와 올바르게 상호작용하는지 테스트 해야된다면 어떻게 테스트해야 될까?

바로 우린 상대 객체가 아니라 테스트 케이스를 통해 잘 상호 작용하는 지 테스트 해보면 됩니다.