[Jest + POM] 유지보수성과 확장성을 고려한 테스트 리팩토링

📌 현재 디렉토리 구조

VSCode/
├── JavaScript_Prac/
│      ├── LoginPage.js
│      └── LoginPage.test.js
├── package.json

 

⬇️ LoginPage.js

const { By } = require('selenium-webdriver');

class LoginPage {
  constructor(driver) {
    this.driver = driver;

    this.emailInput = By.id("email");
    this.pwdInput = By.id("password");
  };

  async getElement(el) {
    return await this.driver.findElement(el);
  }
  
  async getInputValue(locator) {
    const element = await this.driver.findElement(locator);
    return await element.getAttribute("value");
  }

  async sendTxt(el, txt) {
    await this.driver.findElement(el).sendKeys(txt);
  }

  async clickBtn(el) {
    await this.driver.findElement(el).click();
  }
}

module.exports = LoginPage;

 

⬇️ LoginPage.test.js

const { Builder } = require("selenium-webdriver");
const LoginPage = require('./LoginPage.js'); 

const BASE_URL = "http://localhost:3000/login";
const TIMEOUT = 10000;

describe("메인 페이지 객체 모델 테스트", () => {
  let driver;
  let loginPage;

  beforeEach(async () => {
    driver = await new Builder().forBrowser("chrome").build();
    loginPage = new LoginPage(driver); 
    await driver.get(BASE_URL);
  }, TIMEOUT);

  afterEach(async () => {
    if (driver) {
      await driver.quit();
    }
  });

  it("로그인 테스트", async () => {
    const emailValue = "asdf@naver.com";
    const pwdValue = "asdf1234";

    await loginPage.sendTxt(loginPage.emailInput, emailValue);
    await loginPage.sendTxt(loginPage.pwdInput, pwdValue);

    const actualEmailValue = await loginPage.getInputValue(loginPage.emailInput);
    const actualPwdValue = await loginPage.getInputValue(loginPage.pwdInput);

    expect(actualEmailValue).toBe(emailValue);
    expect(actualPwdValue).toBe(pwdValue);
  });
});

 

⬇️ package.json

{
  "dependencies": {
    "jest": "^29.7.0",
    "selenium-webdriver": "^4.31.0"
  },
  "scripts": {
    "test": "jest"
  }
}

 

JavaScript와 Jest에 적응하고자 간단한 테스트 코드를 작성해봤다. 워낙 단순한 구조라 문제 없이 잘 작동하긴 했지만, 코드를 들여다보니 금세 개선해야 할 부분들이 눈에 띄었다.

 

🔥 문제점 1

첫 번째 문제는 LoginPage 클래스의 생성자 내부에 locator를 직접 정의한 것이다. 처음엔 간단하게 보이지만, 시간이 지날수록 유지보수가 점점 어려워진다. 예를 들어, 페이지 구조가 변경되어 로그인 버튼의 ID가 loginBtn에서 submitBtn으로 바뀌었다고 가정해보자. locator가 클래스 내부에 정의되어 있다면, 이 파일을 열어 직접 수정해야 한다. 단순히 수정만 하면 되지 않느냐고 생각할 수 있지만, 페이지가 많아지고 공통 요소들이 여러 곳에 중복되기 시작하면 상황이 달라진다. 같은 요소를 여러 클래스에서 중복 정의하고 있었다면, 그걸 모두 찾아가며 수정해야 하는 상황이 발생한다. 결국 변경에 유연하지 못한 구조가 되고, 작은 UI 변경에도 코드 전체를 들쑤셔야 하는 비효율이 생기는 것이다.

 

🔥 문제점 2

두 번째 문제는 테스트 데이터의 하드코딩이다.  LoginPage.test.js 파일 안에 이메일과 비밀번호 값을 직접 넣어놓는 방식은 딱 1개의 경우만 테스트할 수 있을 뿐이며, 다른 케이스를 추가하려면 테스트 코드를 반복 작성해야 한다. 테스트 케이스가 많아질수록 중복도 증가하고, 관리가 번거로워진다.

 

💡 해결책

그렇다면 이 문제들을 어떻게 해결할 수 있을까? 해답은 바로 모듈화다.

 

📌 변경된 디렉토리 구조

VSCode/
├── JavaScript_Prac/
│ ├── pages/
│ │      ├── LoginPage.js
│ │      └── LoginPage.locator.js
│ ├── tests/
│ │      ├── LoginPage.test.js
│ │      └── data/
│ │           └── loginData.js
│ ├── package.json

사실 디렉토리 구조는 본인의 취향에 따라 자유롭게 구성하면 된다. 만약 회사에서 제공하는 공식 구조가 있다면 거기에 맞추면 되는 것이고, 개인 프로젝트라면 본인이 관리하기 편한 방식으로 설정하면 된다. 이번에는 간단한 테스트를 진행해본 거라 디렉토리 구조도 임시로 구성했지만, 페이지 수가 많아진다면 locators 폴더를 따로 만들어 관리하는 것이 훨씬 좋을 것 같다.

 

⬇️ LoginPage.js

class LoginPage {
  constructor(driver) {
    this.driver = driver;
  }

  async getElement(locator) {
    return await this.driver.findElement(locator);
  }
  
  async getInputValue(locator) {
    const element = await this.driver.findElement(locator);
    return await element.getAttribute("value");
  }

  async sendTxt(locator, txt) {
    await this.driver.findElement(locator).sendKeys(txt);
  }

  async clickBtn(locator) {
    await this.driver.findElement(locator).click();
  }
}

module.exports = LoginPage;

 

⬇️ LoginPage.test.js

const { Builder } = require("selenium-webdriver");
const LoginPage = require("../pages/LoginPage.js");
const Locator = require("../pages/LoginPage.locator.js");
const loginData = require("./data/loginData.js");

const BASE_URL = "http://localhost:3000/login";
const TIMEOUT = 10000;

describe("로그인 테스트 (데이터 기반)", () => {
  let driver;
  let loginPage;

  beforeEach(async () => {
    driver = await new Builder().forBrowser("chrome").build();
    loginPage = new LoginPage(driver);
    await driver.get(BASE_URL);
  }, TIMEOUT);

  afterEach(async () => {
    if (driver) {
      await driver.quit();
    }
  });

  test.each(loginData)("로그인 시 입력값 확인: 데이터 (%s)", async ({ email, password }) => {
    await loginPage.sendTxt(Locator.emailInput, email);
    await loginPage.sendTxt(Locator.pwdInput, password);

    const actualEmail = await loginPage.getInputValue(Locator.emailInput);
    const actualPwd = await loginPage.getInputValue(Locator.pwdInput);

    expect(actualEmail).toBe(email);
    expect(actualPwd).toBe(password);
  });
});

 

⬇️ LoginPage.locator.js

const { By } = require('selenium-webdriver');

const LoginPageLocator = {
  emailInput: By.id("email"),
  pwdInput: By.id("password")
};

module.exports = LoginPageLocator;

 

⬇️ loginData.js

module.exports = [
    { email: "asdf@naver.com", password: "asdf1234" },
    { email: "test@example.com", password: "pass1234" },
    { email: "hello@world.com", password: "securepass" }
];

 

loginData.js에 총 3개의 테스트 데이터를 정의했기 때문에, test.each()를 통해 각 데이터에 대해 테스트가 한 번씩 실행된다. 그 결과 Tests: 3 passed로 표시된다. 하지만 실제로는 이 모든 테스트가 하나의 테스트 파일(LoginPage.test.js) 내에서 수행되기 때문에 Test Suites: 1 passed로 출력되는 것이다.

 

📌 리팩토링을 통해 얻은 교훈

이처럼 효율적이고 확장 가능한 자동화 테스트 코드를 작성하기 위해서는, 기능과 데이터를 모듈화하고, 구조화된 패턴(POM 등)을 바탕으로 테스트 설계를 체계화하는 것이 중요하다. 작은 리팩토링에서 시작하더라도, 그 경험은 실제 서비스의 품질과 유지보수 효율을 높이는 데 큰 도움이 된다.