저장 뒤 “완료”가 보이면 성공이라고 정했는데 그 글자가 원래 화면에 있었다면 어떨까. 클릭이 실패해도 검사는 통과한다. 나는 행동 전에도 기대 조건을 읽고 이미 참이면 전달을 멈추게 했다. 실행과 무관한 성공을 만들지 않으려는 기준이었다.

존재 확인과 변화 확인은 다른 질문이다

“저장”이라는 단어가 화면에 있다는 조건은 저장 버튼 이름만 읽어도 맞을 수 있다. 이전 저장의 완료 안내가 남아 있을 수도 있다. 행동 뒤 원하는 내용이 있다는 사실만으로 그 행동이 새 결과를 만들었다고 판단할 수는 없다.

현재 Broker는 clickAndWait와 pressEnter 전에 기대를 inspect로 확인한다. 텍스트나 상태 기대라면 관련 검색어를 써 필요한 부분을 읽는다. 이미 맞으면 EXPECTATION_ALREADY_TRUE로 끝낸다. 이때는 결과를 빨리 찾았다는 성공이 아니라 검증 조건이 부족하다는 거절이다. 아직 새 행동을 보내지 않았으므로 외부 저장이 실패했다는 보고로도 쓰지 않는다.

더 구체적인 결과는 업무에서 정한다

검색을 새로 실행한다면 현재 검색어와 결과 경로를 함께 볼 수 있고, 선택을 바꾼다면 대상 상태의 false→true를 볼 수 있다. 어떤 조건이 필요한지는 업무 의미에 따라 다르다. 아무 안내 문구 하나를 새 성공으로 정하는 방식보다 실제 바뀌어야 할 값에서 출발한다.

이것이 모든 결과에 증가 숫자를 붙이라는 뜻은 아니다. 외부 서비스에 없는 결과 ID를 만들어 성공 증거처럼 쓰지도 않는다. 원래 페이지가 제공하는 확인 가능한 차이를 찾고 부족하면 확인 한계를 남긴다. 조건을 작성하는 사람의 판단과 도구의 기계적 비교가 함께 필요했다.

거절 뒤 검증 없는 클릭으로 우회하지 않는다

이미 참인 기대가 발견되면 explicitExpectationRequired가 켜진다. 다음에 browser.click으로 바꾸어 조건 없이 누르는 우회를 막는다. 호출자가 오류를 없애려고 확인을 제거하면 원래 문제를 해결한 것이 아니기 때문이다.

대기 시간만 늘리는 것도 마찬가지다. 행동 전부터 참인 문구는 오래 기다려도 새로운 증거가 되지 않는다. 조건을 다시 읽어 바꿀 근거가 필요하다. 나는 실패를 통과시키는 수정과 검증할 수 있도록 대상을 더 정확히 정의하는 수정을 구별했다.

상태 기대는 같은 이름의 유일성도 필요하다

state 기대는 대상이 정확히 하나이고 해당 field가 기대 값과 같은지 본다. 같은 이름의 체크박스가 두 개면 하나의 checked만 보고 통과하지 않는다. 텍스트 비교와 URL 비교도 각각 다른 규칙을 가진다. 모든 기대를 같은 문자열 포함 검사로 만들지 않았다.

다만 행동 전 거짓이고 뒤에 참이라고 모든 인과관계를 증명하는 것은 아니다. 페이지의 다른 작업이 같은 상태를 만들 수 있다. 서비스의 저장 ID나 실제 기록 확인이 더 필요한 업무라면 별도 검증을 연결해야 한다. 이 비교는 관찰된 전환의 경계이고 외부 시스템 전체의 완전한 증명은 아니다.

두 번째 키가 전송되지 않았는지 본다

네이티브 Enter fixture는 첫 검색 결과를 확인한 다음 같은 “검색 완료 1”을 기대하며 다시 Enter를 요청한다. EXPECTATION_ALREADY_TRUE를 확인하고 실제 enterCount가 1인지 본다. 검증 실패 전에 키가 이미 전송되지 않았는지까지 확인하는 시험이다.

이 글은 그 시험과 현재 Broker·기대 비교 코드를 읽었다. 현재 실서비스의 검색을 새로 반복한 시험은 아니다. 기존 시험의 합성 횟수 확인과 실제 외부 저장의 완료는 다른 근거다. 나는 오류 이름과 변경 횟수, 적용 연산을 함께 남겨 어떤 보호가 확인됐는지 설명한다.

완료 문구를 만들 때도 변화 기준을 생각한다

업무 화면의 완료 안내가 너무 일반적이면 사람도 어느 작업의 결과인지 헷갈린다. 저장한 항목이나 시점, 처리 상태를 정확히 설명하면 에이전트의 검증뿐 아니라 사용자 이해에도 도움이 된다. 단순히 초록색 “성공”을 보여 주는 것만으로 충분하지 않을 수 있다.

나는 버튼을 누르는 절차를 만들 때 어떤 변화가 그 행동의 결과인지 먼저 묻게 됐다. 이미 있던 상태를 새 성공으로 세지 않는 작은 검사가 자동화 보고의 신뢰도를 바꾼다. 조건을 확인할 수 없다면 확정하지 않고 남기는 것도 프로그램의 정상 동작으로 다뤄야 한다.