시각적 비즈니스 로직 테스트: 무엇을 먼저 자동화할까?

시각적 비즈니스 로직에서 흔히 잘못되는 점

시각적 워크플로는 논리를 눈으로 확인할 수 있어서 더 안전하다고 느껴집니다. 하지만 자주 변경되고 작은 편집만으로도 실제 사용자 경로가 깨질 수 있습니다. 그래서 노코드 도구에서도 시각적 비즈니스 로직 테스트가 중요합니다.

대부분 실패를 일으키는 것은 워크플로의 "큰 아이디어"가 아닙니다. 문제는 작은 연결 고리입니다: 조건이 바뀐다(AND vs OR), 기본값이 바뀐다, 단계가 잘못된 순서로 실행된다, 또는 에러 분기가 건너뛰어진다. AppMaster에서는 Business Process가 편집되거나 Data Designer 필드 이름이 바뀌거나 API 응답 형태가 진화할 때 이런 상황을 보게 됩니다.

많은 실패는 눈에 띄지 않습니다. 모든 것이 배포되고 UI는 로드되지만, 워크플로가 잘못된 메시지를 보내거나 중복을 만들거나 차단되어야 할 것을 승인해 버립니다. 수동 점검은 화면이 멀쩡하면 문제를 놓치기 쉽습니다.

목표는 모든 것을 테스트하지 않고도 빠른 피드백을 얻는 것입니다. 핵심 로직이 바뀌었을 때 경고하는 소규모 자동화 검사를 원하고, 엣지 케이스나 시각적 다듬기는 수동으로 남겨둡니다.

커버리지를 실용적으로 생각하는 방법은 서로 보완하는 세 계층입니다:

• 핵심 경로를 엔드투엔드로 실행하는 워크플로 수준 테스트(요청 제출 -> 검증 -> 승인 -> 알림).
• UI와 통합이 기대하는 입력/출력이 여전히 일치하는지 확인하는 API 계약 검사.
• 모델 변경 후에도 동일하게 재구성할 수 있는 재현 가능한 테스트 데이터.

예: 고객지원 앱에 "환불 승인" 워크플로가 있다면 모든 화면을 테스트할 필요는 없습니다. 한도 초과 요청이 항상 매니저로 라우팅되는지, 상태가 올바르게 업데이트되는지, 이메일이나 Telegram으로 전송되는 메시지에 올바른 필드가 포함되는지만 확신하면 됩니다.

워크플로, API, UI를 위한 간단한 테스트 맵

무엇을 테스트하는지(로직)와 어디서 실행되는지(워크플로, API, UI)를 분리하면 테스트가 쉬워집니다. 목표는 모든 것을 모든 곳에서 테스트하는 것이 아니라, 기능이 여전히 작동함을 증명하는 가장 작은 조각을 고르는 것입니다.

"유닛 스타일" 로직 검사는 한 번에 하나의 규칙(계산, 조건, 상태 변경)에 집중합니다. 빠르고 오류 위치를 정확히 알려주지만, 여러 단계가 연쇄될 때만 나타나는 문제는 놓칩니다.

워크플로 수준 테스트는 중간 계층입니다. 명확한 상태에서 시작해 현실적인 입력을 워크플로에 넣고 중요한 결과(생성된 레코드, 변경된 상태, 전송된 알림, 거부된 동작)를 단언합니다. AppMaster에서는 전체 UI를 클릭하지 않고 Business Process를 끝까지 실행하는 경우가 많습니다.

엔드투엔드 UI 테스트는 최상위에 위치합니다. 배선(wiring) 문제를 잡을 수 있지만 느리고 깨지기 쉽습니다. UI만으로 의존하면 테스트 고치는데 더 많은 시간을 쓰게 됩니다.

가장 작은 신뢰 가능한 테스트 조각을 고를 때 다음 순서가 잘 작동합니다:

• 기능이 여러 단계나 역할을 포함하면 워크플로 수준 테스트로 시작하세요.
• UI나 통합이 동일한 엔드포인트에 의존하면 API 계약 검사를 추가하세요.
• 로그인, 체크아웃, 요청 제출 같은 핵심 사용자 경로에 대해서만 UI 테스트를 사용하세요(1~2개).
• 임계값, 권한 같은 까다로운 규칙에는 유닛 스타일 검사를 사용하세요.

승인 프로세스의 경우: 요청을 Draft에서 Approved로 이동시키는 한 개의 워크플로 테스트, status 필드를 일관되게 유지하는 계약 검사 하나, 사용자가 요청을 제출할 수 있음을 증명하는 UI 테스트 하나 정도면 됩니다.

먼저 자동화할 것(그리고 당장은 수동으로 둘 것)

작은 로직 버그가 가장 큰 피해를 주는 곳부터 자동화를 시작하세요. 보통 금전, 권한, 고객 데이터와 연결된 워크플로가 우선 순위입니다. 잘못되면 잘못된 금액을 청구하거나 기록을 노출시키거나 사용자를 차단할 수 있는 경우 최우선입니다.

다음으로 의도적으로 복잡한 워크플로를 목표로 삼으세요: 단계와 분기, 재시도, 통합이 많은 경우입니다. 데모의 "행복 경로(happy path)"에서 놓친 조건이 API가 느리거나 결제가 실패하거나 사용자가 특이한 역할을 가질 때 실제 사고로 이어집니다.

빈도도 중요합니다. 하루에 수천 번 실행되는 워크플로(주문 생성, 티켓 라우팅, 비밀번호 재설정)는 한 달에 한 번 실행되는 관리자 프로세스보다 자동화를 우선시해야 합니다.

테스트를 작성하기 전에 결과를 측정 가능하게 만드세요. 좋은 자동화 테스트는 "보기에는 괜찮다"가 아니라 "레코드 X는 상태 Y로 끝나고, 이 부수 효과들이 정확히 한 번 발생했다"입니다. AppMaster Business Processes에서는 입력, 예상 상태 변경, 예상 호출이나 메시지로 명확히 표현할 수 있습니다.

자동화 우선순위를 빠르게 판단하는 필터:

• 틀리면 영향이 큰 경우(금전, 접근, 민감 데이터)
• 분기나 외부 서비스가 많이 관여하는 경우
• 자주 실행되거나 많은 사용자에 영향을 미치는 경우
• 나중에 디버깅하기 어려운 경우(무음 실패, 비동기 단계)
• 한 문장으로 작성 가능한 명확한 합/불합 조건이 있는 경우

탐색적 검사, 시각적 레이아웃, 아직 발견 중인 엣지 케이스는 수동 테스트로 남겨두세요. 동작이 안정되고 무엇을 "성공"으로 볼지 모두 동의할 때 자동화하세요.

실제 로직 오류를 잡는 워크플로 수준 테스트

워크플로 수준 테스트는 유닛 검사 바로 위 단계에 있습니다. 워크플로를 블랙박스로 보고: 트리거하고 최종 상태와 부수 효과를 검증합니다. 사용자가 실제로 느끼는 오류는 여기서 잡힙니다.

하나의 트리거와 하나의 중요한 결과를 이름으로 정하세요. 예: "요청이 제출되면 상태가 Pending이 되고 승인자에게 알림이 전송된다." 이 조건이 유지되면 작은 내부 리팩터는 대부분 문제를 일으키지 않습니다.

결과를 바꾸는 분기만 커버하고 모든 노드를 검사할 필요는 없습니다. 간결한 세트 예시는:

• 성공 경로(모든 것이 유효하고 사용자가 권한이 있음)
• 검증 실패(필수 필드 누락, 형식 오류, 금액 범위 초과)
• 권한 거부(사용자는 볼 수는 있지만 행동할 수 없음)

그 다음 워크플로가 실제로 실행되었음을 증명하는 부수 효과를 점검하세요: PostgreSQL에 생성되거나 업데이트된 레코드, 변경된 상태 필드, 전송된 메시지(이메일/SMS 또는 Telegram)를 확인합니다.

테스트를 짧게 유지하는 패턴은 "트리거, 그리고 결과 단언"입니다:

• 트리거: 최소 입력을 만들어 워크플로를 시작(API 호출, 이벤트, 버튼 액션)
• 최종 상태: 상태, 소유자/담당자, 타임스탬프
• 부수 효과: 새 레코드, 감사 로그 항목, 큐에 쌓인 알림
• 비즈니스 규칙: 한도, 필수 승인, "자기 자신의 요청 승인 불가"
• 놀라움 없음: 추가 생성 없음, 중복 메시지 없음

여기서는 픽셀 단위의 UI 확인을 피하세요. 버튼이 이동했더라도 비즈니스 규칙은 변하지 않습니다. UI 모양과 상관없이 워크플로가 보장해야 하는 것을 단언하세요.

각 워크플로 테스트는 한 가지 결과에 집중하세요. 하나의 테스트가 다섯 가지 규칙과 세 가지 부수 효과를 검증하려 하면 읽기 어렵고 고치기 고통스럽습니다.

무음 실패를 막는 API 계약 검사

API 계약은 API가 지키기로 한 약속입니다: 무엇을 받는지, 무엇을 반환하는지, 어떻게 실패하는지. 이 약속이 예고 없이 바뀌면 최악의 버그가 발생합니다: 모든 것이 정상처럼 보이다가 특정 경로에서 실제 사용자에게 문제가 생깁니다.

계약 검사는 워크플로가 API 호출에 의존할 때 이를 보호하는 빠른 방법입니다. 비즈니스 로직의 정확성은 증명하지 못하지만, 무작위 UI 실패로 나타나기 전에 깨지는 변경을 잡아냅니다.

계약에서 고정해야 할 항목

클라이언트를 조용히 깨트리는 경향이 있는 항목부터 시작하세요:

• 일반적인 결과에 대한 상태 코드(성공, 검증 오류, 금지, 찾을 수 없음)
• 요청과 응답의 필수 필드(어떤 필드가 null이 될 수 있는지)
• 필드 타입과 형식(숫자 vs 문자열, 날짜 형식, enum 값)
• 검증 메시지(정확한 텍스트가 아니라 안정적인 키/코드)
• 에러 형태(에러가 어디에 있는지, 여러 에러는 어떻게 반환되는지)

부정 테스트도 의도적으로 포함하세요: 필수 필드 누락, 잘못된 타입 전송, 권한 없이 액션 시도. 이런 테스트는 저렴하면서 워크플로와 API 간의 가정 불일치를 드러냅니다.

AppMaster로 빌드하는 경우 모델이나 로직 변경 후 앱을 재생성할 때 계약은 더 중요합니다. 필드 이름 변경, 검증 규칙 강화, 새로운 필수 속성은 백엔드가 성공적으로 컴파일되어도 이전 클라이언트나 통합을 깨트릴 수 있습니다.

계약 검사를 어디서 실행할까

하나의 신뢰 가능한 장소를 선택하고, 더 빠른 피드백이 필요할 때만 추가하세요:

• 핵심 엔드포인트 변경 시 CI에서 매번 실행
• 스테이징 배포 후 환경 특이 문제 포착
• 야간 실행으로 광범위한 커버리지를 확보

호환성 기대치에도 합의하세요. 이전 클라이언트가 계속 작동해야 한다면 필드 제거나 의미 변경은 버전화된 변경으로 처리하세요. 작은 리팩터로 보지 마세요.

신뢰할 수 있는 재현 가능한 테스트 데이터

워크플로 테스트는 항상 동일한 상태에서 시작할 때만 도움이 됩니다. 재현 가능한 테스트 데이터는 예측 가능하고 다른 테스트와 격리되며 쉽게 재설정되어 이전 실행이 다음 실행에 영향을 주지 않습니다. 많은 테스트 노력이 여기서 조용히 실패합니다.

역할과 워크플로가 의존하는 핵심 레코드를 포함한 작은 시드 데이터셋을 유지하세요: Admin 사용자, 매니저, 일반 직원, 고객 1명, 활성 구독 1개, 그리고 문제 사례 1건(연체 송장 등). 이러한 시드를 테스트 전반에서 재사용하면 로직 검증에 시간을 쓰고 데이터를 재창조하는 데 시간을 낭비하지 않습니다.

추가 테스트를 추가하기 전에 환경을 깨끗한 상태로 되돌리는 방식을 결정하세요:

• 매 실행마다 테스트 환경을 처음부터 재구성(느리지만 매우 깨끗)
• 실행 사이에 핵심 테이블을 잘라내기 또는 비우기(빠르지만 주의 필요)
• 각 테스트가 건드는 것만 다시 생성(가장 빠르지만 실수하기 쉬움)

핵심 검사는 무작위성을 피하세요. 탐색적 실행에서는 무작위 이름, 타임스탬프, 금액을 써도 되지만, 핵심 검사에서는 고정값(예: InvoiceTotal = 100.00)을 사용하고 테스트가 규칙을 증명할 때만 하나의 변수를 바꾸세요.

또한 각 워크플로 테스트에 필요한 최소 데이터를 문서화하세요: 어떤 사용자 역할, 어떤 상태 필드, 어떤 관련 엔터티가 Business Process 시작 전에 존재해야 하는지. 테스트 실패 시 로직이 깨졌는지 설정이 잘못되었는지 빠르게 판단할 수 있습니다.

모델 변경을 견디는 테스트 만들기

모델 변경은 "좋은" 테스트가 갑자기 실패하는 가장 큰 원인입니다. 필드 이름을 바꾸거나 테이블을 분리하거나 관계를 변경하거나 Data Designer를 업데이트해 AppMaster 앱을 재생성하면 테스트 설정이 여전히 이전 형태로 쓰기를 시도합니다. 더 심한 경우, 테스트가 내부 취약한 ID에 의존하면 틀린 것을 검사하면서도 통과할 수 있습니다.

데이터베이스 ID나 자동 생성되는 UUID를 하드코딩하는 것은 흔한 함정입니다. 이러한 값은 비즈니스 의미를 담고 있지 않으며 시드 데이터 재배치, 환경 재구성, 엔터티 추가 등으로 바뀔 수 있습니다. 테스트는 이메일, 주문 번호, 외부 참조, 사람이 읽을 수 있는 코드 같은 안정적인 비즈니스 식별자에 고정하세요.

현재 모델에서 테스트 데이터 생성하기

테스트 데이터를 작은 제품 기능처럼 취급하세요. 지난달 모델이 아니라 오늘의 모델에 기반해 엔터티를 생성하는 데이터 빌더를 사용하세요. 필수 필드가 추가되면 빌더 하나만 업데이트하면 모든 테스트가 혜택을 봅니다.

항상 같은 역할(Requester, Approver), 한 부서, 한 샘플 고객 같은 소수의 정형화된 엔터티 세트를 유지하세요. 이렇게 하면 워크플로 테스트가 읽기 쉬워지고 일회성 픽스처가 쌓이지 않습니다.

스위트 안정성을 유지하는 규칙:

• 단언에는 내부 ID가 아닌 비즈니스 키(예: employee_email)를 사용하세요.
• 엔터티 생성을 빌더에 중앙화하세요(필드 변경 시 한 곳만 고치면 됩니다).
• 대부분의 워크플로를 커버하는 5–10개의 정형화된 레코드를 유지하세요.
• 시드 데이터가 여전히 로드되는지 확인하는 마이그레이션 체크 테스트를 추가하세요.
• 필수 필드나 관계가 바뀌면 빠르게 실패하고 명확한 오류를 출력하세요.

그 마이그레이션 체크 테스트는 단순하지만 강력합니다. 시드 데이터가 더 이상 모델에 맞지 않으면 여러 워크플로 테스트가 혼란스럽게 실패하기 전에 즉시 알 수 있습니다.

AppMaster 프로젝트에서 특히 주의할 점

AppMaster는 빠르게 움직이기 쉽게 해주므로 앱이 빠르게 형태를 바꿀 수 있습니다. 시각적 및 모델 변경을 "나중에 확인하자"가 아니라 테스트 트리거로 다루세요. 시각적 비즈니스 로직 테스트는 모델 변경 중에 문제를 잡을 때 가치가 커집니다, 사용자에게 문제가 생긴 뒤에 잡는 것이 아니라.

Data Designer(PostgreSQL 모델)를 편집할 때는 이전 시드 데이터가 더 이상 맞지 않을 수 있다고 가정하세요. 필드 이름 변경, 새로운 필수 열, 관계 변경은 설정 스크립트를 깨뜨려 테스트가 잘못된 이유로 실패하게 만듭니다. 각 데이터 모델 업데이트를 시드 데이터를 새로고침하는 신호로 사용해 테스트가 현실적이고 깨끗한 기준에서 시작되도록 하세요.

Business Process Editor 업데이트도 동일한 규율이 필요합니다. 워크플로가 변경되면(새 분기, 새 상태, 새 역할 체크) 워크플로 수준 테스트를 즉시 업데이트하세요. 그렇지 않으면 테스트는 통과하지만 현실 프로세스와 맞지 않는 거짓된 안전감이 생깁니다.

API의 경우 엔드포인트 변경을 계약 스냅샷과 연결하세요. 입력 또는 출력이 바뀌면 같은 작업 세션에서 계약 검사를 업데이트해 웹앱이나 모바일 앱에 무음으로 깨지는 변경을 배포하지 않도록 하세요.

각 테스트 환경에서 다음을 재확인하세요:

• 인증 규칙과 역할(사전구성된 인증을 사용하는 경우 특히 중요)
• 활성화된 모듈(Stripe 같은 결제, Telegram/이메일/SMS 같은 메시징)
• 통합 설정과 시크릿, 또는 테스트 더블의 명확한 사용
• 구성에 영향을 주는 배포 가정(클라우드 vs 자체 호스팅)

예: 새로운 필수 Department 필드를 추가하고 BP 단계가 자동 라우팅하도록 조정했다면, 시드 사용자에 부서를 추가하고 승인 워크플로 테스트를 새로운 라우팅을 단언하도록 업데이트하세요. AppMaster는 시각 모델에서 깔끔한 소스 코드를 재생성해주어 드리프트를 줄이는 데 도움이 되지만, 테스트가 구현 세부가 아니라 동작(출력, 상태, 권한)에 초점을 맞출 때만 효과적입니다.

첫 신뢰 가능한 테스트 스위트를 설정하는 단계별 계획

모델이나 화면이 바뀌어도 반드시 작동해야 하는 것을 고르세요. 보통 돈, 승인, 접근, 고객 약속을 옮기는 워크플로가 해당됩니다.

중요 워크플로의 짧은 목록을 작성하고 결과를 한 문장으로 정의하세요. "매니저가 승인한 인보이스가 결제 요청을 생성한다"는 테스트 가능하지만 "승인이 작동한다"는 표현은 모호합니다.

각 워크플로에 최소한의 시드 데이터를 만드세요. 작고 명명하여 로그에서 쉽게 찾을 수 있도록 하세요: 역할별 사용자 1명, 계정 1개, 상태별 문서 1개. AppMaster에서는 이것을 Data Designer 모델과 정렬해 필드가 진화해도 데이터가 일관되게 유지되도록 합니다.

먼저 워크플로 수준에서 상단 몇 개의 흐름만 엔드투엔드로 자동화하세요. 예: 승인 워크플로를 시작하고 매니저 결정을 시뮬레이션한 뒤 최종 상태(승인, 감사 기록 생성, 알림 전송)를 확인합니다.

그 흐름들이 의존하는 엔드포인트에 대해서만 API 계약 검사를 추가하세요. 모든 것을 테스트하려는 게 아니라 워크플로를 조용히 깨뜨릴 수 있는 형태 변경을 잡는 것이 목적입니다.

실행을 재현 가능하게 만드세요:

• 각 실행 전에 DB를 재설정(또는 전용 테스트 스키마 사용)
• 최소한의 시드 데이터만 재주입
• 변경 시마다 테스트 실행(릴리스 전만이 아니라)
• 명확한 실패 출력 저장: 워크플로 이름, 입력, 최종 상태
• 실제 버그가 놓치거나 새 기능이 출시될 때만 커버리지 확장

이렇게 하면 스위트가 작고 빠르며 시각적 로직 확장에 따라 유용하게 유지됩니다.

워크플로 테스트를 불안정하게 만드는 흔한 실수

불안정한(flaky) 테스트는 아예 없는 것보다 더 해롭습니다. 실패를 무시하도록 만들고 실제 로직 오류가 통과합니다. 가장 큰 원인은 워크플로를 UI 스크립트로 취급하는 것입니다.

클릭을 과도하게 자동화하는 것은 고전적인 함정입니다. 버튼을 누를 수 있다는 것을 증명해도 올바른 결과가 발생했다는 것을 증명하진 않습니다. 더 나은 검증은 워크플로가 올바른 레코드를 생성했는지, 올바른 상태를 설정했는지, 올바른 메시지를 보냈는지를 확인하는 것입니다. AppMaster에서는 일반적으로 Business Process가 생성한 결과(필드, 전이, 부수 효과)를 검증합니다.

또 다른 불안정성 원인은 지저분하게 공유된 테스트 계정입니다. 팀이 하나의 "테스트 사용자"를 재사용하면 수백 건의 오래된 요청, 이상한 권한, 남은 초안으로 인해 새 실행이 가끔만 실패합니다. 각 실행에 새 사용자를 쓰거나 동일한 소규모 데이터셋을 알려진 상태로 되돌리는 편이 낫습니다.

모델이 바뀌는 순간 깨지는 가정도 피하세요. ID 하드코딩, 레코드 순서에 의존, "목록의 첫 번째 항목 선택" 같은 방식은 취약합니다. 안정적 키(외부 참조, 이메일, 테스트에서 설정한 코드)로 레코드를 선택하세요.

초기에 고치면 좋은 패턴:

• 행복 경로만 테스트해 권한 오류, 필드 누락, 거부 상태를 테스트하지 않는 경우
• UI 단계로 로직을 증명하려고 하고 감사 로그와 워크플로 결과를 확인하지 않는 경우
• 스텁 없이 라이브 외부 서비스(결제, 이메일/SMS)에 의존하는 경우
• 서서히 오염되는 장기 사용 테스트 계정을 공유하는 경우
• ID 하드코딩하거나 정렬/타임스탬프 일관성을 가정하는 경우

예: 예산이 없으면 제출을 차단해야 하는 승인 워크플로가 있다면, 거부를 예상하고 명확한 오류 상태를 기대하는 부정 테스트를 작성하세요. 이 한 테스트가 클릭 스크립트 더미보다 더 많은 회귀를 잡는 경우가 많습니다.

테스트를 추가하기 전에 하는 빠른 체크리스트

새 테스트를 추가하기 전에 그것이 가치가 있는지 확인하세요. 빠르게 스위트를 키우는 가장 쉬운 방법은 읽기 어렵고 재실행하기 어렵고 깨지기 쉬운 테스트를 추가하는 것입니다.

새 테스트를 작은 제품 기능처럼 다루는 습관이 유용합니다: 명확한 목표, 안정적 입력, 분명한 합/불합.

사전 점검 목록:

• 기대 결과를 한 문장으로 설명할 수 있는가(예: "승인된 요청이 인보이스를 생성하고 재무팀에 알린다")?
• 데이터를 재설정하고 같은 결과로 테스트를 세 번 실행할 수 있는가?
• 각 중요 워크플로에 대해 적어도 한 개의 부정 사례(필수 필드 누락, 잘못된 역할, 한도 초과)를 가지고 있는가?
• 워크플로가 API를 건드리면 상태 코드나 데이터 타입, 에러 형식 등 계약을 검사하는가(단순히 "200 OK"만 확인하지 않는가)?
• 데이터 모델이 바뀌면 빌더/픽스처 같은 공유된 몇 곳만 업데이트하면 되는가, 아니면 하드코딩 값을 찾아다녀야 하는가?

AppMaster로 개발 중이라면 테스트 레코드를 앱이 실제로 사용하는 같은 API나 Business Process를 통해 생성하는 재사용 가능한 설정 단계를 선호하세요. 이렇게 하면 테스트가 실제 동작에 가깝게 유지되고 모델이 진화할 때 파편화를 줄일 수 있습니다.

예: 승인 워크플로를 과도하게 테스트하지 않고 검증하기

내부 승인 앱을 상상해보세요: 요청자가 구매 요청을 제출하면 승인자가 검토하고 요청은 명확한 상태를 거쳐 이동합니다. 가치는 단순합니다: 올바른 사람이 요청을 올바른 다음 상태로 이동시킬 수 있어야 합니다.

가장 중요한 동작만 테스트로 시작하세요:

• Approve: 승인자가 요청을 "Pending"에서 "Approved"로 옮기고 누가 언제 승인했는지 감사 필드가 설정되는지
• Reject: 승인자가 요청을 "Rejected"로 옮기고 이유 입력이 필수인지
• Request changes: 승인자가 "Needs changes"로 옮기고 요청자가 재제출할 수 있는지

승인 엔드포인트 주변에 하나의 API 계약 검사를 추가하세요. 예를 들어 워크플로가 POST /requests/{id}/approve를 호출한다면 다음을 확인하세요:

• 응답 코드(성공은 200, 잘못된 역할은 403 등)
• 응답 형태(status가 알려진 값인지, updated_at 존재 여부)
• 기본 규칙(예: 상태가 "Draft"에서 바로 "Approved"로 점프할 수 없음)

테스트 데이터는 작고 재현 가능하게 유지하세요. 로직에 필요한 것만 시드하세요: 한 명의 요청자, 한 명의 승인자, "Pending" 상태의 요청 1개. 고정된 식별자(예: 고정 이메일)를 사용하면 재생성 후에도 같은 레코드를 쉽게 찾을 수 있습니다.

이제 모델 변경을 상상해보세요: cost_center 같은 새 필수 필드를 추가하면 많은 테스트가 옛 형태로 요청을 만들어 실패합니다.

모든 테스트를 다시 쓰는 대신 공통된 "요청 생성" 헬퍼(또는 시드 단계) 하나를 업데이트해 cost_center를 포함하도록 하세요. 워크플로 테스트는 상태 전이에 집중하고, 계약 검사는 요청이나 응답 스키마의 새 필드를 잡아낼 것입니다.

다음 단계: 스위트를 작고 유용하게 최신 상태로 유지하기

사람들이 신뢰하는 테스트 스위트만 도움이 됩니다. 스위트가 빠르게 커졌다가 방치되면 신뢰가 사라집니다. 비즈니스 가치가 있는 소수의 워크플로에 집중하세요.

우선순위 워크플로 목록을 작은 반복 가능한 테스트 백로그로 전환하세요. 각 워크플로에 대해 한 문장으로 설명할 수 있는 명확한 통과 조건을 부여하세요. "완료"가 무엇인지 설명할 수 없다면 테스트도 모호해집니다.

대부분 팀에 효과적인 간단한 리듬:

• 변경 시마다 실행되는 5~10개의 고가치 워크플로 테스트 유지
• 월간 정리로 죽은 테스트 삭제하고 시드 데이터를 갱신
• 프로덕션에 버그가 도달하면 그 버그를 잡을 하나의 테스트 추가
• 테스트 데이터를 작고 명명해 실패 원인 파악을 쉽게 함
• 실패를 주간으로 리뷰하고 테스트나 워크플로를 즉시 고침

정리 작업은 실제 작업입니다. 워크플로가 변경되어 기존 테스트가 현실을 반영하지 않으면 즉시 삭제하거나 다시 작성하세요.

AppMaster(appmaster.io)로 워크플로와 API를 빌드 중이라면, 동일한 가시성을 사용해 구체적인 결과를 정의하고 작은 워크플로 수준 검사를 초기에 고정하세요. 데이터 모델이 진화할 때 테스트를 일치시키는 가장 쉬운 방법입니다.