Pintos Test Explorer - Pintos 테스트를 VS Code 사이드바 GUI로

실사용 영상

--------------

Pintos를 구현하다 보면 테스트를 터미널에서 반복해서 실행하게 된다.

테스트 하나를 실행하려면 현재 작업 중인 프로젝트의 빌드 디렉터리를 확인하고, 정확한 Make 타깃을 입력해야 한다. 실행이 끝나면 생성된 결과 파일을 찾아 실제로 테스트가 통과했는지도 확인해야 한다.

Pintos는 하나의 프로젝트가 아니라 여러 단계로 나뉘어 있어서 이 과정이 더 복잡해진다.

Threads
User Programs
Virtual Memory
File System

각 프로젝트는 서로 다른 빌드 디렉터리를 사용하고, 테스트 결과도 여러 파일로 생성한다.

처음에는 VS Code에 테스트 실행 버튼만 추가하면 된다고 생각했다.

그런데 실제로 만들어보니 테스트 실행은 전체 과정의 일부에 불과했다. 확장 프로그램이 테스트를 찾아서 그룹으로 나누고, 실행 결과를 판별하고, 생성된 파일을 보여주려면 Pintos 빌드 구조 전체를 이해해야 했다.

그래서 만든 것이 Pintos Test Explorer다.

Pintos 테스트는 일반적인 단위 테스트가 아니다

일반적인 테스트 프레임워크는 테스트 목록과 실행 결과를 구조화해서 제공한다.

Pintos는 조금 다르다. 테스트가 Makefile을 통해 등록되고, 기존 Pintos 빌드 시스템으로 실행된다.

개별 테스트는 다음과 같은 Make 타깃으로 실행한다.

make tests/threads/alarm-zero.result

이 명령은 단순히 테스트 함수 하나만 실행하는 것이 아니다.

개념적으로는 다음 과정이 포함된다.

Pintos 커널 빌드
→ 테스트 프로그램 빌드
→ 디스크 이미지 준비
→ QEMU로 Pintos 실행
→ 커널 안에서 테스트 실행
→ 커널 출력 저장
→ 호스트의 검사 프로그램 실행
→ 최종 결과 저장

따라서 확장 프로그램이 새로운 테스트 실행기를 만드는 것보다는 Pintos가 이미 제공하는 Make 타깃을 그대로 사용하고, 그 결과를 보기 쉽게 보여주는 편이 자연스러웠다.

세 종류의 결과 파일

Pintos 테스트를 실행하면 다음 세 종류의 파일이 생성될 수 있다.

*.output
*.result
*.errors

각 파일의 역할은 다르다.

파일	내용
output	Pintos 커널의 실행 출력
result	호스트 검사 프로그램이 기록한 최종 결과
errors	빌드 또는 실행 준비 중 발생한 오류

처음에는 테스트 코드 안에서 pass()가 실행되면 테스트가 성공한 것이라고 생각하기 쉽다.

하지만 pass() 메시지는 커널 실행 출력의 일부일 뿐이다.

테스트 프로그램에서 pass() 호출
→ 메시지가 .output에 기록됨
→ 호스트 검사 프로그램이 전체 출력 검사
→ 최종 PASS 또는 FAIL을 .result에 기록

따라서 확장 프로그램은 .output이 아니라 .result를 읽어 최종 상태를 표시한다.

.result가 PASS
→ PASS

.result가 FAIL
→ FAIL

정상적인 result가 생성되기 전에 빌드 중단
→ BUILD ERROR

이 구분이 사이드바 상태 표시의 기준이 되었다.

Pintos 사이드바 만들기

package.json에는 VS Code Activity Bar에 전용 Pintos 영역을 등록했다.

Activity Bar
└─ Pintos
   └─ Pintos Tests

확장 프로그램에서는 다음 명령들을 제공한다.

테스트 목록 새로고침
개별 테스트 실행
개별 테스트 디버깅
체크한 테스트 일괄 실행
현재 테스트 이후 일괄 실행 중단
테스트 소스 파일 열기
결과 파일 열기
테스트 결과 초기화
사용자 테스트 생성 및 관리

사이드바는 프로젝트와 테스트 그룹을 트리 형태로 보여준다.

Pintos Tests
├─ Threads
│  ├─ Alarm Clock
│  │  ├─ alarm-single
│  │  ├─ alarm-multiple
│  │  └─ alarm-zero
│  ├─ Priority
│  └─ MLFQS
├─ User Programs
├─ Virtual Memory
└─ File System

각 테스트에는 다음 네 가지 상태 중 하나가 표시된다.

Not run
PASS
FAIL
Build error

결과 파일이 존재하면 테스트를 펼쳐서 확인할 수 있다.

alarm-zero
├─ output
├─ result
└─ errors

각 항목을 선택하면 해당 파일이 VS Code에서 바로 열린다.

트리 구조 만들기

사이드바는 extension.js의 PintosTreeProvider를 중심으로 구현했다.

트리는 여러 종류의 노드로 구성된다.

ProjectNode
GroupNode
TestNode
ArtifactNode

이들의 관계는 다음과 같다.

프로젝트
→ 테스트 그룹
→ 개별 테스트
→ 생성된 결과 파일

프로젝트와 그룹에는 하위 테스트의 요약 정보도 표시한다.

전체 테스트 수
PASS
FAIL
Build error
Not run
체크된 테스트 수

따라서 모든 테스트를 펼치지 않아도 프로젝트의 전체 진행 상태를 확인할 수 있다.

Threads · 18/24 passed

하위 테스트 중 하나라도 실패했으면 프로젝트나 그룹을 빨간색으로 표시한다. 실패가 없고 통과한 테스트가 존재하면 녹색으로 표시한다.

Pintos 루트 디렉터리 찾기

모든 Pintos 저장소가 같은 디렉터리 구조를 사용하는 것은 아니다.

워크스페이스 자체가 Pintos 루트일 수 있다.

workspace/
├─ threads/
├─ userprog/
├─ vm/
└─ tests/

다른 저장소 안에 pintos/ 디렉터리로 들어 있을 수도 있다.

workspace/
└─ pintos/
   ├─ threads/
   ├─ userprog/
   └─ tests/

어떤 환경은 src/ 또는 pintos/src/를 사용하고, 교육용 저장소에서는 Pintos가 Docker나 실습용 프로젝트 안에 중첩되어 있기도 하다.

그래서 확장 프로그램은 다음 구조를 모두 확인한다.

현재 디렉터리
현재 디렉터리/pintos
현재 디렉터리/src
현재 디렉터리/pintos/src

상위와 하위 디렉터리도 탐색하지만 .git, node_modules, build 같은 폴더는 제외한다.

다음 파일들이 모두 존재해야 Pintos 루트로 판단한다.

utils/pintos
threads/Make.vars
userprog/Make.vars
vm/Make.vars
tests/Make.tests

단순히 tests 디렉터리가 있다는 이유만으로 일반 프로젝트에서 확장 프로그램이 동작하지 않도록 한 것이다.

테스트 실행 과정

사용자가 Run 버튼을 누르면 먼저 해당 프로젝트의 빌드 디렉터리가 준비되어 있는지 확인한다.

빌드 트리가 없다면 프로젝트 디렉터리에서 make를 실행한다.

threads/
→ make
→ threads/build/

그다음 선택한 테스트의 기존 결과 파일을 삭제한다.

이 과정은 이전 실행에서 남아 있는 .result가 새로운 실행 결과로 잘못 표시되는 것을 방지하기 위해 필요하다.

실제 테스트는 기존 Make 타깃을 이용해 실행한다.

make -C threads/build \
  --no-print-directory \
  tests/threads/alarm-zero.result

전체 흐름을 정리하면 다음과 같다.

Run 버튼 클릭
→ 프로젝트 빌드 디렉터리 확인
→ 빌드 트리 준비
→ 기존 output, result, errors 삭제
→ 테스트의 .result Make 타깃 실행
→ Pintos와 QEMU가 테스트 실행
→ 새 .result 파일 확인
→ 사이드바 갱신

Pintos가 정상적인 결과를 생성하기 전에 Make가 실패하면 확장 프로그램은 BUILD_ERROR 결과를 만들고 최근 빌드 출력을 .errors에 저장한다.

이를 통해 일반적인 테스트 실패와 빌드 실패를 구분할 수 있다.

여러 테스트 실행하기

테스트, 그룹 또는 프로젝트에 있는 체크박스를 이용해 여러 테스트를 선택할 수 있다.

테스트 체크
→ Run Checked Tests
→ 선택된 테스트를 순서대로 실행

각 테스트는 같은 빌드 환경을 사용하고 QEMU 프로세스를 실행할 수 있기 때문에 순차적으로 실행한다.

일괄 실행을 중단하는 기능도 추가했다.

중단 버튼은 실행 중인 Make나 QEMU 프로세스를 즉시 종료하지 않는다.

현재 테스트 완료
→ 남은 테스트 건너뛰기
→ 완료된 테스트만 요약

현재 빌드 디렉터리나 결과 파일이 불완전한 상태로 남는 것을 줄이기 위한 방식이다.

모든 실행이 끝나면 다음과 같은 요약을 출력한다.

18 passed, 2 failed, 20 total

결론

실제 구조는 이렇게 되었다.

VS Code 사이드바
→ 프로젝트와 테스트 탐색
→ 올바른 빌드 디렉터리 결정
→ 기존 Pintos Make 타깃 실행
→ output, result, errors 확인
→ PASS, FAIL, BUILD ERROR 표시

다음 문제는 VS Code 사이드바와 터미널이 같은 테스트 목록과 실행 규칙을 사용하도록 만드는 것이었다.

다음 글에서는 pt CLI, Makefile 기반 테스트 탐색, GDB 디버깅, 사용자 테스트 관리 과정을 정리해보려고 한다.