자동화된 테스트 케이스가 개발에 어떤 효과를 주는지 정리해 봤습니다.

1. 자동화된 test case의 효과 플랫폼 TL팀 임도형 책임

2. 본 문서의 목적 자동화된 test case의 효과에 대한여 기술한다.

3. 자동화된 테스트 케이스란?

4. 테스트 케이스란? 동작 확인을 위한 특정 시나리오에 해당하는 코드를 의미한다. 예) 함수 sum()에 2와3을 입력하면 5가 반환된다. assertEqual(sum(2,3), 5); 모든 코드는 테스트 되어 진다. 단 재활용 하지 못할 뿐이다. printf()로 동작확인을 위한 코드는 대부분 주석처리 되거나 삭제된다. printf(“%i, %i”, sum(2,3), 5); 재활용 하기 위하여 정형화된 방법으로 테스트 코드를 작성하자는 것이다. 보통 특정 프레임웤을 사용한다. Junit, CppUnit같은.

5. 자동화? 자동화 되지 않는 테스트 코드는 재활용 되기 힘들다. 테스트용 어플리케이션이 잘 재활용 될까? 컴파일 방법, 실행 방법을 일일이 명시해야 한다. 정형화 되지 않아 제각각이다. 이 코드를 SCM에 포함시켜야 하나? 테스트 케이스가 많아 지면 일일이 사람 손으로 할 수 없다. 어짜피 자동화 해야 한다. 자동화 하더라도 그 결과를 자동적으로 취합할 수 있어야 한다. 사람 손이 필요없이 실행할 수 있는 것을 의미.

6. 효과

7. 효과 수정 시의 생산성 향상 버그 잡기가 빨라진다. 버그 잡기가 쉬워진다. 시스템 구조가 좋아진다. 리팩토링의 조건 회귀테스트를 제공한다. 하위호환성 보증의 방법을 제공한다. 전체 시스템의 이해 없이 부분의 수정이 가능하다. 샘플로 활용된다. 코드 리뷰 시에 부담감이 준다. CI가 제대로 활용된다. 설계와 구현을 분리할 수 있다.

8. 효과 – 수정 시의 생산성 향상 자동화된 테스트 케이스가 없다는 것은 모든 테스트를 손으로 해야 한다는 것이다. 작은 수정이라도 기존의 테스트를 전부 손으로 해야 한다. 소프트웨어는 매일마다 수정된다. 매일마다 손으로 테스트해야 한다. 이를 자동화 하면 생산성이 향상된다.

9. 효과 – 버그 잡기가 빨라진다. 자동화 할 수 있는 테스트 케이스가 없는 경우, 보통 한번에 몰아서 테스트 한다. 한달에 한번? 만약 테스트 케이스가 있다면 언제나 테스트를 실행할 수 있다. 만약 테스트 케이스가 없다면? 방금 수정한 것에 의한 버그가 한달 뒤에 QA팀에 의해 보고 된다. 혹은 6달 뒤에 고객에게서 알려져 온다. 몇 달 전의 기억을 되살려, 혹은 문서를 뒤적여 로직을 파악해야 한다. 테스트 케이스가 있다면 수정 직후 테스트 케이스를 돌리고, 버그 여부를 그자리에서 파악한다.

10. 효과 – 버그 잡기가 쉬워진다. 방금 만들어진 버그의 존재를 그 자리에서 확인할 수 있다. 생생한 개발 상황이 아직 머리에 올라가 있을 때 버그를 확인하고 잡아낼 수 있다. 타인이 작성한 코드에서의 버그를 파악할 때도 그 시작점을 기존 테스트 케이스로 할 수 있다.

11. 효과 – 시스템 구조가 좋아진다. 인수 테스트나 통합 테스트가 아닌 경우는 각 단위별로 테스트 된다. 시스템 단위 컴퍼넌트 단위 클래스 단위 메소드 단위 각 단위 별로 테스트를 하려면 각 단위의 독립성이 절대적이다. 서로 얽힌 코드들은 테스트 하기도 어렵다. 테스트를 고민하다 보면 서로 엮인 부분을 풀게 되고, 시스템 구조가 좋아진다. 시스템 설계 부터 테스트를 고려해야 한다. 혼자서 테스트 할 수 없는 컴퍼넌트는 존재하지 않는다.

12. 효과 – 리팩토링의 조건 리팩토링은 외적으로는 변경되지 않으면서 내부를 개선하는 것이다. 기능 추가가 아니다. 소프트 웨어 개발에 필수적인 항목이다. 그런데 외적으로 변경되지 않는다는 것을 어떻게 보증하지? 오직 테스트 케이스 뿐이다. 테스트 케이스가 없이는 리팩토링이 불가능하다.

13. 효과 –회귀테스트를 제공한다. 회귀 테스트는 기존에 잘 동작하던 것을 다시 확인하는 테스트 이다. 기능 추가, 수정, 버그 픽스 등으로 인해 멀쩡하던 것이 오동작 하면 안된다. 계속 추가해온 테스트 케이스는 이러한 정상 동작의 확인해 사용된다. 즉 회귀테스트에 활용된다.

14. 효과 – 하위호환성 보증의 방법을 제공한다. 제품이 업그레이드될 때, 기존의 환경에서도 잘 동작하는지를 확인해야 한다. 업그레이드가 진행될 수록 고려할 가지 수는 팩토리알 단위로 증가한다. 기존에 작성된 테스트 케이스는 자연스럽게 하위호환 확인에 사용될 수 있다.

15. 효과 – 전체 시스템의 이해 없이 부분의 수정이 가능하다. 한 부분의 수정에 따른 영향도 분석은 실제로는 불가능하다. 어느 정도의 분석조차도 불가능하다. 유일한 방법은 실제 동작시켜보는 것이며, 동작 확인은 테스트 케이스에 의한다. 시스템의 전체를 이해하지 않고, 부분만을 이해한 경우라도 기존의 모든 테스트가 성공했다면 수정에 의한 영향이 없다고 판단할 수 있다.

16. 효과 – 샘플로 활용된다. 테스트 케이스의 코드가 곧 본 코드의 사용예가 된다. 테스트 케이스 작성 시에 불편하다는 것은 본 코드의 사용이 불편하다는 것을 의미한다. 본 코드의 파악에 좋은 첫걸음은 샘플이다. 곧 테스트 케이스가 이 용도로 사용되기 좋다. 문서 작성 시에 따로 샘플 코드를 작성하지 말고 테스트 케이스의 코드를 활용한다.

17. 효과 – 코드 리뷰 시에 부담감이 준다. 모든 코드 로직을 파악하는 것이 아닌, 작성된 테스트 케이스들만을 가지고 정상 동작 여부를 파악할 수 있다. 내부 로직을 코드로 이해하는 것보다, 외부에서 입출력 관계로 로직의 목적을 이해하는 것이 더 쉽다.

18. 효과 – CI가 제대로 활용된다. CI? Continuous Integration, 지속적인 통합 막판에 한번의 통합이 아닌 평소에 꾸준히 통합하자는 것. 보통 tool을 사용한다. 소소가 수정되면 SCM에서 소스를 가져와 자동 컴파일 그리고 자동화된 테스트를 진행 보통 daily build라고도 한다. ‘컴파일 성공’+ ‘테스트 성공’ 상태의 유지가 목적이다. 그런데 테스트 케이스가 없으면 반쪽뿐이다. 컴파일 되는 것만을 보장한다. 이것은 지속적 통합이 아니다.

19. 효과 – 설계와 구현을 분리할 수 있다. 테스트 케이스에서 본 코드 중에 사용하는 코드는 인터페이스 부분이다. 내부 구현은 관여하지 않는다. 인터페이스의 정의와 이 인터페이스의 동작을 확인한다. 인터페이스를 설계하고그 인터페이스를 코드로 정의만한 상태에서, 테스트 케이스 작성이 가능하다. 본 코드 개발이란, 이렇게 미리 작성된 테스트 케이스를 성공하도록 하는 작업이다.

20. 단점

21. 단점 개발 시에 테스트 케이스 자체에 시간이 걸린다.

22. 테스트 케이스 코드의 양 보통은 본 코드의 양 만큰 테스트 케이스 코드가 작성된다. 적당량은 상황에 따라 다르지만 함수 하나에 케이스 하나는 최소한 아닐까?

23. Special Thanks! Are There Any Other Questions?