 | Effective Unit Testing -  라쎄 코스켈라 지음, 이복연 옮김/한빛미디어 |
테스트
흔하지만 내 것은 아닌 그런 것이다. 한창 회자할 때의 부채 의식은 아주 옅어졌지만, 아직도 양심의 가책처럼 늘 남아 있는 계륵 같은 존재가 테스트 주도 개발이다. 사용하면 좋을 것이라고 심정적으로는 동의한다. 그러나 SI 프로젝트는 개발 과정과 딜리버리 이후의 상황보다는, 구축 과정의 시간적 제약을 극복하는 것이 우선이라 테스트 코드를 보기는 쉽지 않다.테스트 코드가 생각날 때
다시 볼 것 같지(보고 싶지) 않았던 코드를 직접 기능 개선해야 하는 일이 가끔 생긴다. 간단한 기능 추가라면 별일 없겠지만, 고려할 사항이 많은 경우라면 상황은 자못 심각해진다. 망각이 인생에 도움이 된다지만, 이런 경우는 원망스럽기도 하다. 그럴 때면 지금처럼 테스트 코드에 대한 애틋한 감정이 다시금 되살아난다. 내친김에 책장에서 Effective Unit Testing을 꺼내 들었다.테스트의 가치
테스트를 제대로 사용하려면 먼저 테스트에 대한 인식을 바꿔야 한다. 테스트란 작성한 코드의 기능을 검증하는 것이 목적이 아니라, 구현할 코드의 명세를 확정하는 것이다.1. 설계: 테스트 코드 작성
2. 구현: 테스트 성공을 위한 코드 구현
3. 리팩토링
그런 의미에서 테스트 주도 개발이란 1, 2, 3의 과정을 반복하는 것이다. 테스트를 코드 설계를 위한 도구로 활용할 때, 결과적으로 생산성은 향상될 것이다.
SOLID 설계 원칙
로버트 마틴이 고안한 설계 원칙이다.1. 단일 책임 원칙: Single responsibility principle
a. 클래스를 수정해야 하는 이유는 오직 하나뿐이어야 한다.
2. 개방 폐쇄 원칙: Open-Closed Principles
a. 클래스는 확장을 위해서는 개방적이되 수정에 대해서는 폐쇄적이어야 한다. 즉 코드 수정 없이도 클래스의 기능을 변경할 수 있도록 하자는 이야기
3. 리스코프 치환 원칙: Liskov Substitution Principle
a. 상위 클래스는 하위 클래스로 대체될 수 있어야 한다.
4. 인터페이스 분리 원칙: Interface Segregation Principle
a. 하나의 범용 인터페이스보다 쓰임새별로 최적화한 인터페이스 여러 개가 낫다는 원칙이다.
5. 의존 관계 역전 원칙: Dependency Inversion Principle
a. 코드는 구현체가 아닌 추상 개념에 종속되어야 한다.
단위 테스트의 구조
단위 테스트는1. Arrange (준비)
2. Act (시작)
3. Assert (단언)
의 구조를 가진다. 참고로 행위 주도 개발에서는
1. Given (주어진 상황에서)
2. When (어떤 일이 발생했을 때)
3. Then (특정 결과를 기대한다)
를 사용한다고 한다. 행위 주도 개발이 좀 더 성숙한 개념인 것 같다.
0 댓글