마이크로서비스 아키텍처 구축(전면 개정판)

362

2

부

구현

십상이다. 가치를 더하는 것과 그에 수반되는 부담을 두고 균형 잡힌 대화를 하기란 어렵다. 또

한 위험과 보상에 대한 절충안도 어려운 일이 될 수 있다. 테스트를 제거하면 사람들이 고마워

할까? 그럴지도 모르지만, 여러분이 제거한 테스트가 버그를 허용한다면 비난이 따를 것이 분

명하다. 그러나 더 큰 범위의 테스트 집합에 대해 생각하자면 확실히 제거할 수 있어야 한다.

동일한 기능이

20

개의 서로 다른 테스트에서 검증되고 있고 실행하는 데

10

분이 걸린다면, 아

마도 그중 절반은 반드시 제거해야 할 것이다! 제거 위험을 더 잘 이해해야 하지만, 이는 인간

이 잘 해내지 못하는 것으로 유명하다. 결과적으로 더 큰 범위의 고비용 테스트를 지능적으로

선별하고 관리하는 사례는 결코 흔치 않다. 사람들이 이 작업을 더 많이 수행하길 바라지만 실

제는 그렇지 않다.

9.4.49.4.4

대규모 적체 대규모 적체

엔드투엔드 테스트와 관련된 긴 피드백 주기는 단지 개발자 생산성 문제에만 해당되는 것은 아

니다. 오래 걸리는 테스트 집합을 사용하면 중단된 것을 수정하는 데 시간이 걸리므로 엔드투

엔드 테스트가 통과될 것으로 예상되는 시간이 줄어든다. 모든 테스트를 성공적으로 통과한 소

프트웨어만 배포한다면 (그렇게 해야 한다! ) 운영 환경에 배포할 수 있는 지점까지 도달할 서

비스가 더 적다는 의미다.

이것은 적체로 이어진다. 고장 난 통합 테스트 단계를 수정하는 동안 업스트림 팀의 더 많은 변

경이 누적될 수 있다. 이로 인해 빌드를 수정하는 ...