방법론 스터디 1회 - 테스트 시작하기

🧪 테스트란?

테스트란,
“코드가 의도한 대로 동작하는지 확인하고 검증하는 행위”를 의미한다.
단순히 console.log()로 확인하는 것도 일종의 테스트지만, 자동화된 방식으로 구조 있게 검증하는 것이 소프트웨어 테스트의 핵심이다.
이번 스터디에서는 테스트가 단순한 오류 확인을 넘어서, 설계와 유지보수에도 큰 영향을 준다는 점을 처음 알게 되었다.

---

🧪 테스트를 처음 접하며

이번 스터디를 통해 테스트라는 걸 처음으로 제대로 접했다.
단순히 코드가 잘 돌아가는지를 확인하는 정도가 아니라, 테스트가 설계와 코드 완성에 영향을 줄 수 있다는 얘기를 들었을 땐 솔직히 좀 놀라웠다.
console.log 찍는 것도 테스트라고 생각했는데, ‘테스트 구조를 나눠서 작성하는 방식’이 존재한다는 걸 이번에 처음 알게 됐다.

---

💡 왜 테스트가 중요할까?

마틴 파울러는 테스트를 먼저 작성하면 기능 구현보다 인터페이스 설계에 집중하게 된다고 한다.
테스트가 통과된 시점이 곧 코드 완성 시점이라는 말도 꽤 인상 깊었다.
구글 엔지니어링 문화에서는 테스트된 코드는 전체 유지 기간 동안 버그 발생이 적다는 점을 강조한다.
이런 이야기를 접하면서, 테스트는 단순한 확인 단계를 넘어서 더 좋은 개발을 위한 습관이 될 수 있겠다는 생각이 들었다.

---

✅ 좋은 테스트의 4가지 원칙

발표에서 언급된 테스트의 4가지 원칙은 다음과 같다.

1. 인터페이스 중심: 내부 구현 X, public 메서드 기준으로 테스트 작성
2. 커버리지보다 의미: 단순 유틸은 생략 가능
3. 가독성: 테스트 코드만 읽어도 앱의 동작을 이해할 수 있어야 함
4. 단일 책임: 테스트 하나당 하나의 동작만 검증

이 네 가지를 듣고, "테스트도 하나의 설계도처럼 구조적으로 작성되어야 한다"는 걸 처음 실감했다.

---

⚙️ 테스트 작성 방식 – AAA와 GWT

이번 스터디에서 테스트를 구조화하는 방식으로 두 가지를 새롭게 접했다.
하나는 AAA 패턴, 다른 하나는 GWT 패턴이다.
둘 다 이번에 처음 알게 된 방식들이라, 개념을 따라가는 것만으로도 새로운 경험이었다.

---

⚙️ AAA 패턴

AAA (Arrange - Act - Assert)는 가장 기본적이고 널리 쓰이는 테스트 구조다.

• Arrange: 테스트 준비
• Act: 동작 수행
• Assert: 결과 검증

it("버튼 클릭 시 onClick이 호출된다", () => {
  const handleClick = jest.fn(); // Arrange
  render(<button onClick={handleClick}>Click</button>);

  fireEvent.click(screen.getByText("Click")); // Act

  expect(handleClick).toHaveBeenCalled(); // Assert
});

처음에는 단순해 보였는데, 이렇게 단계별로 나눠서 작성하면 테스트 목적이 분명해지고 테스트를 쪼개서 관리하기도 수월해진다는 걸 알게 되었다.
또, 발표에서 나온 "Act-Assert가 반복되면 테스트를 쪼개야 한다"는 기준도 인상 깊었다.
테스트 작성 경험이 거의 없는 나에게는 일종의 체크리스트처럼 느껴졌다.

---

📜 GWT 패턴

GWT(Given - When - Then)도 이번 스터디에서 처음 접한 방식이다.
주로 **시나리오 기반 테스트(사용자 행동 흐름)**나 BDD(Behavior-Driven Development, 행위 주도 개발) 스타일의 테스트에 쓰인다고 한다.
예를 들면, “로그인한 사용자가 장바구니 버튼을 클릭하면, 상품이 장바구니에 추가된다” → 이게 시나리오 기반이고
이걸 GWT 형식으로:

• Given: 사용자가 로그인한 상태에서
• When: 장바구니 버튼을 클릭하면
• Then: 상품이 장바구니에 추가된다
• → 이게 BDD 스타일

개인적으로는 AAA 구조보다 조금 더 말처럼 읽히는 구조여서, 테스트를 설명하는 데 좋겠다는 느낌이 들었다.

---

📗 마틴 파울러의 정리

발표 내용 중 일부를 다시 보면, GWT는 예제를 통해 시스템 동작을 명세하는 방식이고, 테스트를 문서처럼 활용할 수 있는 구조라는 설명이 있다.

실제로 같은 단계 안에서 여러 조건이나 결과를 연결할 때 And를 써서 자연스럽게 확장할 수 있다는 점도 흥미로웠다.

• Given 나는 A라는 상태이고
• And B라는 조건도 만족하고 있을 때
• When 어떤 동작을 하면
• Then 이런 결과가 나와야 하고
• And 또 다른 결과도 함께 나와야 한다

이렇게 테스트가 기획서나 명세처럼 쓰일 수 있다는 개념 자체가 새로웠다.

---

🧠 AAA vs GWT 비교 요약

주 용도	단위 테스트	시나리오, BDD 테스트
구조	Arrange → Act → Assert	Given → When → Then
표현 방식	개발자 중심	사용자·업무 흐름 중심
장점	테스트 분리 쉬움	명세서처럼 읽힘

 

---

🙋‍♀️ 느낀 점

처음 테스트라는 걸 접하면서, 무엇보다도 "테스트를 위한 구조가 있다는 것"부터가 놀라웠다.
스터디를 통해 알게 된 용어나 개념을 따라가는 것도 벅찼지만, 다른 사람들의 이야기를 들으며 시야가 넓어지는 경험을 할 수 있었다.
어떤 분은 테스트의 장단점을 구분하고, 대규모 시스템에서 테스트가 얼마나 중요한지까지 생각하고 있었는데, 나는 그보단 아직 AAA, GWT 같은 형식적인 틀을 받아들이는 것만으로도 벅찼던 것 같다.
그래도 그런 이야기를 들을 수 있었기에, 앞으로 테스트를 공부해 나가는 방향에 대해 작은 힌트를 얻은 기분이다.