영상 파일을 고르면 업로더가 파일 이름으로 제목을 미리 채워 주기도 한다. 원하는 값과 같으니 넘어가도 될 것 같지만 실제 입력 이벤트를 기다리는 화면에서는 준비가 끝나지 않을 수 있다. 북극성에서는 이 특정 업로더의 제목을 일반 본문과 같은 단순 값 비교로 끝내지 않았다.

보이는 값과 내부에서 처리한 값을 구분한다

일반 본문에서는 이미 같은 글자가 있으면 다시 입력하지 않는 것이 맞다. page-operation도 기존 문단 값이 같으면 alreadyMatches로 끝날 수 있다. 그런데 영상 제목용 input은 다른 일반 입력 경로이며 특정 ID에 nativeCommitKey=End를 돌려준다. 같은 문자열이 보인다는 조건 하나로 모든 필드를 같은 동작으로 묶지 않은 것이다.

이 차이는 임의의 모든 사이트에 키를 보내자는 규칙이 아니다. 실제로 확인한 업로더의 입력 처리 방식에 맞춘 한정된 연결이다. 화면에 보이는 값과 사이트가 후속 동작에 사용할 값이 언제 같은 상태가 되는지 알아야 했다. 그 사건을 구분하면 엉뚱한 재입력을 줄이면서 필요한 입력만 남길 수 있다.

업로더가 끝나기 전에 제목부터 만지지 않는다

naver-article의 waitMedia는 영상 업로드가 진행 중인지 먼저 본다. 제목 입력란이 속한 프레임의 완료 문구와 유일한 완료 버튼이 확인돼야 제목 단계로 간다. 버튼이 켜져 보이거나 다른 프레임의 완료 글자가 있다는 이유로 앞당기지 않는다. 제목 처리와 매체 처리의 순서도 계약의 일부였다.

기존 시험은 다른 프레임에 완료 문구가 있고 실제 업로더는 늦게 끝나는 상황을 만든다. 그동안 제목을 입력하거나 삽입하면 fixture가 실패하도록 되어 있다. 이번 콘텐츠 작업은 그 시험을 읽은 것이며 실제 외부 업로드를 새로 기다린 결과가 아니다. 시험이 재현한 조건의 범위를 그대로 설명한다.

다른 제목이 있으면 무조건 덮어쓰지 않는다

원하는 제목과 현재 값이 같은지 먼저 verifyField로 비교한다. 같지 않으면 최신 관찰에서 제목 필드를 다시 잡고 빈 값인지 확인한다. 다른 값이 이미 있으면 ARTICLE_VIDEO_TITLE_CONFLICT다. 파일 이름이 자동으로 들어온 경우와 사람이 별도 제목을 적어 둔 경우를 같은 빈 입력처럼 취급하지 않는다.

값이 같거나 비어 있어 진행할 수 있는 경우에도 browser.fill을 명시적으로 호출한다. 제목이 같다는 이유로 이 호출을 생략하지 않는 것이 이 예외의 핵심이다. 원하는 값을 확인하는 비교와 그 값을 사이트가 처리하게 하는 입력을 나누면 왜 같은 문장을 다시 전달하는지 설명할 수 있다.

Enter 대신 값이 바뀌지 않는 End를 쓴다

드라이버는 해당 입력의 nativeCommitKey를 읽고 같은 프레임에서 End의 keyDown·keyUp을 보낸다. Enter는 폼 제출을 일으킬 수 있어 사용하지 않는다는 주석도 있다. 값에 임의 글자를 추가했다 지우는 방식 대신 현재 값을 유지한 입력 사건을 만드는 선택이다.

키를 보냈다는 사실만으로 영상 삽입 완료를 선언하지 않는다. 입력값 검증이 이어지고 원고에서는 전체 구성이 다시 관찰돼야 한다. 참조와 문서가 바뀌면 기존 좌표로 밀어붙이지 않는 검사도 같은 경로에 있다. 한 필드의 작은 예외도 이후 결과 확인을 생략하는 단축키가 되어서는 안 됐다.

시험은 문자열 일치 뒤에도 처리 사건을 요구한다

기존 단위 시험은 미리 채운 제목에서도 video-title 입력이 남고 업로드가1회인지 확인한다. 별도 소유 fixture는 keyup 이후에만 committed 값을 갱신하고 그 값이 맞아야 삽입 버튼이 결과를 만든다. 문자열만 읽는 시험으로는 놓칠 수 있는 입력 처리 조건을 표현한 것이다.

이 글에서는 관련 원본 함수와 시험을 대조했으며 원래 제품의 시험을 다시 실행하지 않았다. 공유 원고 검토 모듈의 영상 제목은 계획 지문에 포함되지만 native 입력이나 실제 제목 commit을 구현하지 않는다. 계획의 동일성 시험을 입력 이벤트의 실화면 검증으로 바꿔 보고하지 않는다.

값 검증이 충분한 곳과 사건이 필요한 곳을 나눈다

자동화에서 모든 필드를 더 많이 누르고 다시 입력하는 것은 해결책이 아니다. 대부분의 같은 값은 재사용해야 하고, 특정 화면이 요구하는 처리 사건만 정확히 넣어야 한다. 나는 화면 종류별 차이를 공통 fill 계약 안에서 제한된 신호로 전달하는 쪽을 택했다.

다른 업무 프로그램에도 자동 완성·선택 확정·계산 반영처럼 보이는 값 뒤에 별도 사건이 있는 경우가 있다. 어떤 값을 언제 확정으로 보는지 직접 관찰하고 그 조건만 시험해야 한다. 영상 제목은 작은 사례지만 값이 맞다와 사이트가 그 값을 받아 처리했다를 구분하는 제작 판단을 보여 준다.