소프트웨어 장인 정신 이야기 (5)

2부. 기준

기준은 기본적인 '기대 수준'이다. 이는 우리가 지켜야 한다고 정한 기준선이다. (...) 기준을 능가하는 건 상관없지만 절대 그에 못 미쳐서는 안 된다.

 

9장. 생산성

여러분의 CTO로서 나는 생산성에 있어 몇 가지를 기대한다.
- 나는 절대 똥덩어리를 출시하지 않기를 기대한다
- 나는 낮은 수정 비용을 기대한다
- 나는 우리가 언제나 준비되어 있기를 기대한다
- 나는 안정적인 생산성을 기대한다

 

10장. 품질

여러분의 CTO로서 나는 품질에 있어 몇 가지를 기대한다.
- 나는 지속적인 개선을 기대한다
- 나는 두려움을 이기는 능력을 기대한다
- 나는 극한의 품질을 기대한다
- 나는 우리가 QA에게 떠넘기지 않기를 기대한다
- 나는 현실적으로 자동화 가능한 모든 테스트가 '자동화되기를' 기대한다

 

자동화 테스트와 사용자 인터페이스

자동화 테스트는 비즈니스 규칙을 사용자 인터페이스를 통해 테스트하지 않아야 한다.

 

왜? → 사용자 인터페이스가 바뀌는 이유는

비즈니스 규칙 이외의 다른 요인(ex 마케팅, 유행이나 기능)과 관련이 더 많기 때문에

테스트가 매우 쉽게 깨지게 되고, 결국 유지 보수가 너무 힘들어 테스트 자체를 버리는 경우가 많기 때문..!

 

그리고 개인적으로는 이것이 프론트엔드 개발에서 테스트와 관련된 논의가 활발하지 않은 이유라 생각한다.

기획/디자인 의 변경은 너무나도 잦고, 이 때마다 모든 테스트가 실패하고 마니까!

사용자 인터페이스를 통해 실행되는 테스트

C.마틴은 위와 같은 상황을 피하기 위해,

아래처럼 개발자가 함수 호출 API를 사용해 비즈니스 규칙을 사용자 인터페이스에서 분리해 내야 한다 고 말한다.

 

api를 통한 테스트는 사용자 인터페이스와 무관

이 API를 사용하는 테스트는 사용자 인터페이스와 완전히 무관하고, 인터페이스 변경에 영향을 받지 않는다.

 

만약 사용자 인터페이스를 테스트해야한다면?

사용자 인터페이스에 미리 정해진 값을 제공하는 스텁

해당 테스트가 비즈니스 규칙과 분리된 상태를 유지하도록 주의해야 하며,

미리 정해진 값을 제공하는 스텁으로 비즈니스 규칙을 대체해 테스트할 수 있다.

 

물론 사용자 인터페이스가 상당히 크고 복잡하다면

자동화된 사용자 인터페이스 테스트 프레임워크(ex StoryBook)을 사용하는 편이 좋을 수도 있고

사용자 인터페이스가 작고 간단하다면, 그냥 수동 테스트에 의존하는 편이 더 빠를 수도 있다.

(두 경우 모두 비즈니스 규칙 스텁을 사용하면 테스트가 더 안정적일 테다)

 

핵심은 → 자동화 가능하다면, 자동화 된 테스트를 수행하는 것!

 

11장. 용기

- 나는 프로그래밍 팀의 팀원들이 서로를 대신할 수 있기를 기대한다
- 나는 여러분의 불확실성을 표현하는 정직한 추정을 기대한다
- 나는 답이 "아니요"일 때 여러분이 "아니요"라고 말하기를 기대한다
- 나는 우리 모두가 지속적이고 적극적으로 학습하기를 기대한다
- 나는 모든 프로그래머가 멘토가 되기를 기대한다