[우아한 개발] - 05. 테스트와 코드 품질 관리하기

잊을 만하면 돌아오는 정산 시스템

정산 시스템을 만들기 위해 필요한 것

기능 요구사항
관리자는 모든 데이터의 생성/조회/수정/삭제, 일반 회원은 검색

주어진 요구사항은 모두 지켯지만, 요구사항으로 명시되어 있지 않더라도 당연히 되어야 하는 것들이 안 되는 경우 발생

개인적으로 '명시되어 있지 않더라도 당연히 되어야 하는 것' === '요구사항'이라고 생각하기 때문에 저 말은 모순이라고 생각... 명시되어 있지 않으면 당연히 해야 되는 것이라기 보다는 오히려 요구사항 작성 측에서 더 자세하게 쓰지 못한 것이 아닌가...

시간을 설정하는 경우 23:59:59로 설정하면, 23:59:59:01의 나노초는 무시되는 현상 발생 => 생각 못해본 문제 나도 쿠키나 게시글 날짜 설정 등에서 시간을 다루는 경우가 많았는데, 이렇게 나노초 같은 경우는 고려해보지 못했다.

유지보수, 확장성, 고가용성 등의 개발 원칙이 있지만 가장 우선되어야 하는 것은 '비즈니스 요구사항을 명확히 충족하는가?', '당연한 것이 당연한 자리에 있는가?'

Controller와 Service 층의 강한 결합
층별로 담당해야 하는 역할을 명확히 하고, 층별 의존 관계를 고려해 유지보수하기 좋은 형태를 만들어야 한다.

추가 리뷰
잘못된 테스트는 독이 될 수 있다.
최대한 예외 케이스부터, 해피 케이스 순서로 다양한 경우를 커버할 수 있어야 한다.

모듈 분리
모듈은 최소 스펙으로, 데이터의 형태는 확장 가능한 형태를 지향한다. 미래를 고려한 설계가 오히려 복잡성을 증가시키는 경향이 있다.
예상 가능한 범위라면 확장성과 유지보수에 좋은 코드를 지향하지만, 불확실한 형태로 모듈을 세분화하면 복잡성을 증가시킬 수 있다.

외부 라이브러리를 사용하는 것
외부 라이브러리를 선택할 때의 기준

제어권의 유무
라이브러리를 수정하거나 수정 요청 등의 작업 및 직접 코드를 제어할 수 있어야 함
공식 지원 유무
프레임워크 차원에서 외부 라이브러리의 의존성을 관리하고 지원하는지
커스텀 지원
확장할 수 있는 형태인지
안정성
많은 사람이 사용하고 검증된 라이브러리인지
마지막 수정/커밋
지속해서 유지보수되고 있는지

배포

AWS EC2를 만들면 서버 시간이 한국 기준으로 설정되어 있지 않다
DB 시간/언어 설정 등

가파르게 성장하는 서비스를 담당한 어느 품질 담당자의 회고

팀의 QA로서 주어진 미션

클라이언트를 테스트할 안정적인 테스트 환경(프론트서버군)을 지원한다
클라이언트 개발 이전에 서버 테스트를 진행한다
서버와 클라이언트를 각각 테스트해 불확실성을 줄이고, 안정된 테스트를 한다
서버의 배포만으로 사용자에게 가치를 전달하는 방향으로 만들어질 수 있도록 지원한다
소프트웨어 설계 시 서버 배포만으로 기능이 변경되도록(기능이 앱 업데이트 없이도 추가, 변경, 삭제 가능하도록) 구현한다
프론트검색서비스팀이 담당하는 모든 제품에 QA로서 관여한다
효과적인 테스트 수행 전략을 세우다
테스트 계획, 테스트 케이스 작성 및 리뷰, 결함 관리
- 기획/개발이 긴밀하게 협업할 수 있는 구조
- 클라이언트 환경과 독립된 서버 사이드 테스트
- 빠른 배포 주기

단위 테스트로 복잡한 도메인의 프론트엔드 프로젝트 정복하기

SCM을 개발할수록 걱정이 늘어간다

도메인과 코드가 복잡해지면서 발생한 걱정거리

새 기능 추가
리팩터링
서비스 동작 확인
협업

SCM에 테스트 작성하기
기존 코드에 테스트를 추가하는 방식

기존에 동작하는 코드를 기반으로 사용자 시나리오를 작성한다.
사용자 시나리오를 기반으로 테스트 코드를 작성한다.
리팩터링

사용자 시나리오 작성
시나리오를 작성할 때, 특정 조건을 기준으로 분기하며 작성한다. 조건을 풀어서 나열하면 조건문이 MECE한지 검증하기도 좋다.

테스트 코드를 통한 리팩터링의 효과
정리되지 않은 코드에 새로운 것을 추가하는 위험이 사라졌고, 테스트 코드가 기존 동작에 대해 안정성을 보장해주어 새 기능 추가에서 발생하는 부작용 걱정이 줄었다.

테스트 작성을 통해 얻은 좋은 효과

컴포넌트를 분리해야 하는 명확한 기준과 근거가 생김. 테스트하기 좋은 코드를 기준으로 나누게 됨.
기능동작에 대한 문서화를 따로 할 필요가 없어짐. 테스트 코드가 명세가 되어 따로 코드를 설명하기 위해 문서화할 필요가 사라짐.
코드가 간결해짐. 자연스럽게 단일 책임 원칙을 지키는 방향이 이루어져 더 나은 구조로 컴포넌트를 분리해 사용하게 됨.
MECE하게 시나리오를 작성해 숨겨진 에지 케이스를 찾아내게 됨.

결론적으로 같이 일하는 사람들과 협업하기 좋고 관리하기 좋은 코드를 고민하게 됨, 그리고 거기서 테스트가 기준이 되어줌

테스트 강의 열심히 듣고, 꼭 도입해야 겠다 다시 한 번 다짐...

자동화된 UI 회귀 테스트 도입하기

자동화된 UI 테스트 도입
자동화 도구를 도입하면 이미 개발된 기능과 개/보수된 기능을 빠르게 테스트하고, 개발 단계에서 문제에 대응할 수 있음
자동화된 UI 테스트 도입의 당위는 비용(인력, 시간) 측면에서 테스트 행위별 수행 시간이 감소하고, 테스트 행위별 수행 빈도가 높아진다는 두 가지 이점이 있음.

테스트 행위별 수행 시간
기존 UI 테스트는 1회 수행 비용이 큰데, 사람이 작성한 테스트 케이스 수행 -> 평가 -> 보고하는 과정이 수작업이기 때문.
테스트 행위별 수행 빈도
개발 마지막 단계 출시 전 사람에 의한 반복적 QA 테스트는 비용이 가장 비쌈. 기능의 복잡도, 구현 범위, 일정 등 검증의 어려움이 있고, 서로 분리된 단위의 테스트만이 수행됨.

Windows Application UI Test Automation
테스트 컴플리트, 라노렉스 스튜디오 등의 상용 도구를 사용하면 자동화된 UI 테스트 작성이 가능.

UI 테스트 자동화의 도입과 평가는 전문 QA팀 없이는 불가능 🙃

정리
몇 가지 조건이 충족된다면 UI 테스트 자동화는 충분히 효율적

UI 테스트를 준비하기 전 기존 테스트 항목을 시나리오에 어떻게 분류하고 나눌 것인지 충분한 고민 필요
꾸준한 유지보수 필요
초기 공격적인 UI 테스트 자동화 작업을 진행해야 안정적으로 자동화가 될 수 있음
개발자, QA 엔지니어 간 충분한 커뮤니케이션 및 협업 필요