인수 테스트는 개발자가 아닌 사람들도 이해할 수 있어야 한다

 

문서에 작성했던 인수 테스트의 내용을 소스코드로 옮긴 테스트 코드가 통과하지 못하고 있었다. 실 사용 화면에서는 DB에 있는 데이터들을 잘 가져오고 있었는데, CodeceptJS로 테스트를 실행하면 계속해서 상태를 가져오지 못하는 것을 확인했다.

 

Chromium 브라우저로 실행되는 인수 테스트는 웹 서버가 동작하고 있음에도 데이터를 가져오지 못하고 있었다.

 

처음에는 실행 순서상으로 페이지가 렌더링되고 상태를 가져오기까지 잠깐 동안 출력될 수 있는 Guard Clause로 인해 테스트를 통과하지 못하는 것인가 싶어 페이지 이동 후 대기하게 하는 식으로 수정해보았지만 여전히 게시물을 가져오지 않았다.

 

동료분과 인수 테스트의 어느 지점에서 막히고 있는지 과정을 하나씩 살펴보았다.

 

// tests/posts_test.js

Scenario('동록된 게시글이 존재하는 경우', ({ I }) => {
  // Given
  I.setupPosts();

  // When
  I.amOnPage('/');
  I.click('운동 찾기');

  // Then
  I.see('축구');
  I.see('2022년 11월 13일 15:00~17:00');
  I.see('잠실종합운동장');
  I.see('3/24명');
  I.see('조회수: 123');
}

// steps_file.js

const backdoorBaseUrl = 'http://localhost:8000/backdoor';

module.exports = function () {
  return actor({
    setupPosts() {
      this.amOnPage(`${backdoorBaseUrl}/setup-posts`);
    },
  });
};

 

데이터베이스를 갱신하는 동작은 잘 작동하고 있었다. 페이지를 넘어간 뒤에 브라우저가 계속 작동하고 있었고, API 응답을 받아 상태로 저장하고 가져오는 로직은 테스트 코드를 통해 검증하고 있었기 때문에 백엔드에서 혹시 오류가 발생하는지 확인했다.

 

 

인수 테스트를 작동시킬 때 실제 서버에서 Access Token을 받지 못해 예외가 발생하고 있었다. 인수 테스트 상에서 출력되는 보호절 구문은 실제로 게시물 데이터들을 가져올 수 없었기 때문에 출력되고 있었다.

 

문제 해결을 위해 인수 테스트 상에서 Access Token을 직접 삽입하기 위해 다음의 로직을 추가해보았지만 Access Token이 브라우저의 로컬 스토리지에 입력되지 않았다.

 

// tests/posts_test.js의 When 구문을 다음과 같이 수정했지만 실패

// When
I.amOnPage('/');
I.setAccessToken({
    token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9'
      + '.eyJ1c2VySWQiOjF9'
      + '.jNVVoRzUDIDEfED_sh3-5zsNkihSbOtuV-fu4RUH3hw',
});
I.click('운동 찾기');

// steps_file.js에 다음 내용을 추가했지만 실패

return actor({
    // ...
    
    // Operations
    setAccessToken({ token }) {
      this.executeScript((setToken) => {
        localStorage.setItem('accessToken', setToken);
      }, token);
    },
    
    // ...
 });

 

문제를 어디서부터 해결해야 할지 동료와 이야기를 나누던 중 생각하지 못했던 부분이 있었다. 인수 테스트는 개발자가 아닌 사람도 내용을 보고 이해할 수 있어야 한다는 점이었다.

 

인수 테스트는 소스코드의 메서드명이나 흐름만 봐도 어떤 동작을 하는지 쉽게 이해할 수 있도록 직관적으로 작성해야 한다.

 

내가 (I)
기능과 관련된 어떤 동작을 하면 (amOnPage, click, fillField ...)
결과를 확인할 수 있다 (see, seeElements, ...)

 

 

그러나 setAccessToken같은 명칭이나, Access Token을 Local Storage에 저장하는 기술과 관련된 동작은 개발자가 아닌 사람이 이해하기 어렵다.

 

따라서 해당 문제는 인수 테스트를 현재 구조에서 어떻게 짜야 할지 고민해서 해결하는 대신, 가짜 로그인 기능을 구현해 해결하기로 결정하고 작업을 스프린트 목록에 추가했다.

 

스스로 오랜 시간 (3~40분 이상) 고민해도 뚜렷한 해결책이 떠오르지 않는다면 잘못된 구조로 작업을 하려 하고 있을 수 있다는 점을 다시 한 번 느꼈다. 동료들과 트레이너님들께 최대한 내 상태를 공유하면서 잘못된 구조로 가고 있었다면 그것을 빨리 인지하고 벗어나려는 노력을 해야 할 것이다.