얼쑤의 녹음 업로드에는 두 종류의 코드가 있습니다. 연결이 끊긴 녹음을 다시 보낼지, 언제 보관 기록을 지울지는 공통 로직입니다. 녹음을 앱의 보관 디렉터리로 실제 이동하는 일은 플랫폼마다 다릅니다. 개발 환경에 Android SDK가 없었을 때도 업로드 판단을 검증할 수 있도록 두 부분을 분리했습니다.

Wasm에서 공통 업로드 로직 검사

공통 코드는 파일의 보관·존재 확인·삭제를 RecordingFiles 인터페이스로 호출합니다. 전송도 인터페이스로 받습니다. Wasm에서 실행한 공통 테스트는 두 인터페이스의 가짜를 넣어, 연결 실패 뒤 기록이 남는지와 같은 세션의 재전송 결과를 확인합니다. 플랫폼의 파일 구현을 불러오지 않아도 테스트가 실행되는 이유입니다.

당시에는 Wasm 테스트 작업에서 필요한 클래스만 골라 실행하는 필터를 사용할 수 없어 전체를 돌렸습니다. 조용한 실행에서는 화면에 결과가 거의 나오지 않아, 테스트 결과 XML에서 실행 수와 실패한 테스트 이름을 확인했습니다. 컴파일에 실패해도 이전 XML이 남을 수 있습니다. 실행 결과와 XML의 파일 시각을 함께 보면 읽고 있는 보고서가 지금 코드의 결과인지 판단할 수 있습니다.

Android 파일 구현을 대역으로 검사

Android 파일 구현에서 쓰는 Context의 표면은 애플리케이션 컨텍스트와 앱 파일 디렉터리를 돌려주는 두 메서드였습니다. 이 둘을 Java 대역으로 만들고, 공통 파일 인터페이스와 Android 구현 파일을 Kotlin 컴파일러로 함께 컴파일했습니다. Java의 getter로 만들면 Kotlin에서 context.applicationContext.filesDir처럼 속성으로 접근하는 부분도 검사할 수 있습니다.

컴파일한 클래스를 임시 폴더에서 실행해 Java 파일 I/O의 이동과 정리까지 확인했습니다. 이 결과로 확인한 범위는 두 파일의 컴파일과 임시 파일 시스템 동작입니다. Android 리소스, 의존성 주입 연결, 기기 권한과 실제 앱 파일 저장 정책은 전체 빌드와 기기에서 따로 확인할 영역으로 남겼습니다. 공통 상태 분기와 플랫폼 동작에 서로 다른 증거를 붙여 어디까지 확인했는지 알 수 있게 했습니다.