건강한개발자블로그

테스트 주도 개발 (TDD)는  더 나은 소프트웨어를 만들기 위한 기법 중 하나다.

테스트 코드를 작성해야 하는이유?

1. 코드의 정상작동 유/무를 확인하기 위해서, 소프트웨어에 대한 피드백 과정이 줄어든다.

( 소프트웨어 출시에 있어 피드백 과정이 줄어드는 것이 프로젝트 전체의 일정으로 보았을때 매우 효율적이다 )

2. 새로운 하부시스템을 전체 프로젝트에 통합하기 전에도 매우 유리하다. 

3. 운영되는 코드에 대해 문제를 빨리 알수 있고 수정이쉽고 비용이 낮아진다.

테스트 코드 작성시 알아아두어야 할것.

1. 최대한 많은 개발자 테스트를 자동화 하는것이 핵심.

2. 테스트 코드 작성에 따라 코드 작성시간이 올라갈 수 있지만 코드의 품질을 생각하여 테스트를 수행하는것이 좋다.

3. 잘못된 테스트 코드는 불필요한 리소스를 낭비할 수 있지만 테스트 코드 작성자가 테스트 코드에 대해 이해하고 적절한 테스트 전략을 세운다면 테스트 코드는 작성하지 않을 이유가 없다.

4. 모든 단계의 소프트웨어 스택과 개발 프로세스에 대해 테스트를 수행해야 한다. 특히 가장 작은 범위에서 테스트를 수행해야 피드백 과정 ( 문제발견 / 수정 )을 줄일 수 있다. 

테스트의 유형

- 유닛 테스트

가장 작은 단위의 기능에 대한 테스트를 단독으로 수행하는 것. 각각의 함수가 정확히 작동하는지 확인하기 위한 것.

- 통합 테스트

통합 테스트를 통해 각각의 단위 모듈을 더 큰 결합체로 통합하여 작동시키는 복합 기능을 검증할 수 있다.

- 시스템 테스트

'end-to-end tests' 이 테스트를 통해 전체 시스템에 대한 요구사항 명세를 확인할 수 있음. 통합된 소프트웨어 스택 전체에 수행되는 테스트로서, 프로젝트에 대한 검수 기준으로 사용됨.

테스트 작성 시기

1. 코드를 작성할때 ( 테스트코드를 같이 작성, 나중에 할 수록 테스트 효과가 줄어듬 )

2. 출시코드에 대해 버그를 수정할 때 ( 코드수정을 바로 하지말고 버그의 원인을 설명하는 실패 유닛 테스트를 작성하라 )

3. 빌드과정에서 테스트를 끼워넣을 수 있도록 하자.

테스트 대상

요구사항에 맞게 테스트하라 ( 어떠한것도 테스트대상이 될 수 있다 )

좋은테스트

1. 짧고 명확한 이름을 가지고 있어 실패했을때 원인파악이 쉬움.

2. 유지보수가 쉬움.

3. 수행에 오랜 시간이 걸리 지않음.

4. 최신 구현 코드(작업물)에 맞춰져 있음.

5. 특별히 머신 설정이 필요 없다.

6. 다른 테스트에 대한 의존성이 없어서 특정 테스트 전후에 실행할 필요가 없다. 외부 상태나 코드상의 어떤 공유 변수에 대한 의존성이 없다.

7. 실제 구현코드를 테스트 한다. ( 복제본이 아님, 복제본은 쓸모없을 수 있음 )

나쁜테스트

1. 일정한 결과값을 갖지 않음 ( 때로는 성공, 때로는 실패 )

2. 유지보수하기 힘든 테스트

3. 지나치게 큰 테스트

4. 하나의 테스트케이스에서 둘 이상을 수행하는 테스트

5. 직접 작성하지 않은 서드파티 코드에 대한 테스트

6. 필요하지 않은 기능에 테스트하는 테스트

7. 기능이 보장되어있는것까지 하는 테스트 ( ex: 속성의 getter, setter에 대한 테스트 )

8. 단 하나의 머신에서만 수행 가능한 테스트

테스트의 형태

- 테스트의 기본 프로세스

배치( 검사를 실행할 준비 ) - 실행 - 검증 ( 예측된 값이 맞는지 검사 실행 )

- 테스트 이름

명확한 테스트 명명을 하는것이 좋음.

테스트의 구조

- 테스트가 코드의 중요 기능을 모두 다른 점을 보장하라.

- 테스트는 중복해서 수행하지 않는다. ( 중복 수행은 노력과 혼란, 유지 보수 비용을 가중시킴 )

- 코드의 특정 행태를 확인하는 테스트를 작성하라.

테스트 유지 보수

- 테스트코드는 깔끔하게 다듬고 리팩토링을 하라.

- 코드를 수정하고 테스트케이스를 제거하지마라 테스트케이스 또한 유지보수를 하라.

출처: 훌륭한 프로그래머 되는 법