문자열 계산기를 테스트 주도 개발(TDD)로 진행하며 느낀 점

이번에 우아한테크코스에서 테크니컬 라이팅 세션을 진행했다. 거기서 기술적인 내용에 대해서 작성해야 했는데, 평소 관심있고 재미있어하는 주제인 테스트 주도 개발에 대해서 작성해보면 좋을 것 같아 해당 내용을 작성했다. 근데 관심있고 재미있어 하는 주제지만 실제로 테스트 주도 개발만으로 개발을 하진 않는다. 그러다보니 이 감각을 잊어버릴 것만 같기도 하고, 프리코스가 본격적으로 시작되기도 해서 1주차 문제인 '문자열 계산기'를 테스트 주도 개발만으로 풀어보았다.

 

PR 링크: https://github.com/yeezy-com/java-calculator-7/pull/1

테스트 주도 개발을 통한 문자열 계산기 구현 by yeezy-com · Pull Request #1 · yeezy-com/java-calculator-7

 

제출하진 않았고, 개인 레포 PR이다. 커밋은 총 125개가 나왔다.

지금부터는 테스트 주도 개발만으로 해보면서 느낀 점을 좀 풀어보려고 한다. 이를 위해 비교군이 있으면 좋을 것 같아서 7기 프리코스 시절에 풀었던 PR을 들고왔다. 근데, 느낀 점 뿐만 아니라 생각의 흐름대로 작성하다보니 글이 가끔 주제를 벗어날 수도 있다. 일단 README를 작성하는 방식이나 세세한 부분들부터 차이가 꽤 많이 났다.

 

왼쪽 - 프리코스, 오른쪽 - 현재

 

프리코스 당시에는 테스트 주도 개발이라는 개념조차 모르고 있었기 때문에, 시작하기 전에 어떤 요구사항이 있을지 고민하는 시간이 길었다. 하지만, 처음부터 모든 것을 생각할 수 없었기 때문에 구현하면서 지속적으로 요구사항을 추가해갔다. 그리고 이러한 사항들을 한 번에 하나씩 구현하지 않고, 계속 다른 요구사항들과 어우러짐을 생각하느라 로직 자체가 수정되는 일도 잦았다.

 

테스트 주도 개발로 풀었을 때는 조금 달랐다. 당장 문제에서 보이는 것들만 짧게 적고 바로 구현을 했다. 그 과정에서 새로운 요구사항이 보이면 당장 그것에 대해 생각하기 보다는 README에 간단히 적기만 했다. 그리고, 한 사이클을 돌고나면 추가된 요구사항에 대해서 다시 사이클을 도는 방식으로 진행했다. 그러다보니 당장 눈 앞에 보이는 요구사항에 좀 더 집중할 수 있었던 것 같다. 그래서 생각보다 로직 자체가 변경되는 일은 없었고, 검증 사이의 관계 정도만 좀 생각했었다.

 

이 부분에 대해선 테스트 주도 개발 자체가 경험을 줬다기에는 조금 애매한 것 같기도 하다. 프리코스를 하던 그때의 나와 지금의 나는 여러 방면에서 차이가 꽤 클 것이기 때문에.. 아, 하지만 진행하던 중에 다른 일을 하고 다시 돌아와 코드를 짤때 테스트 주도 개발이 확실히 도움이 크긴 했다. 이전에는 다시 자리에 앉으면 '내가 뭘 구현하고 있었지?'와 같은 고민으로 시작했던 것 같은데, 테스트 주도 개발은 그 진행도가 확실하게 눈에 보이니까 이러한 현상이 없었다. 특히 이 부분은 커밋을 세세하게 나눠서 더 그런 것 같기도 하다. 근데 커밋은 그저 테스트 주도 개발 진행 과정을 위해 세세하게 남긴 것이지 보통 모든 사이클을 돌고 하나의 커밋을 남기는게 좋을 것 같다.

 

왼쪽 - 프리코스, 오른쪽 - 현재

 

이 부분도 경험의 차이가 크다고 생각하긴 하지만, 테스트 주도 개발은 과한 설계를 어느정도 방지해주는 것 같다. 프리코스 시절에는 자바로 뭔가 개발하는걸 처음 해보기도해서 남들 하듯이 따라했다. 그래서 이번에 비교군이 되진 못할 것 같다. 현재는 Splitter, Calculator 정도로 마무리했다. 그리고 이런 객체를 만드는 과정에서 테스트를 먼저 작성하게 되니까, 인터페이스를 먼저 고민하게 됐다.

 

이게 또 테스트의 목적 자체가 테스트 메서드 이름으로 나타나다 보니까, 인터페이스 이름을 고민하는 시간도 짧았다. 예전 같으면 구현을 먼저 하고 이름을 생각했을 것이다. 이런건 참 테스트 주도 개발의 장점이라고 생각한다.

 

음.. 진부하긴 한데, 리팩터링 과정에서도 두려움이 덜했다. 테스트라는 최소한의 방어막이 존재하니까 내부 구현을 휙휙 바꾸는 것에 큰 두려움이 없었다. 그리고 이건 이번에 진행하면서 알게 된건데, 테스트 주도 개발에서는 '가짜 구현'이 핵심이다. 근데 이 가짜 구현을 '진짜 구현'으로 만드는 것도 리팩터링 과정에 포함된다는 점이다. 예를 하나 들면

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

 

간단하게 이러한 테스트가 있다고 하자. 그리고 현재는 red 단계에 해당한다. 그러면 테스트 주도 개발에서는 이를 빠르게 green으로 만들기 위해서 이런 방식으로 구현할 것이다.

 

public class Calculator {

	public int sum(int n1, int n2) {
		return 6;
	}
}

 

이게 바로 테스트 주도 개발에서 말하는 '가짜 구현'이다. 이전에는 이러한 가짜 구현을 진짜 구현으로 만들기 위해서는 비슷한 테스트를 계속 여러 개 만들어가며 green 단계를 거쳐야 한다고 생각했었다. 예를 들면 이런 방식이다.

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

@Test
void 두_수의_합을_반환한다2() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(4, 4);

	assertThat(sum).isEqualTo(8);
}

@Test
void 두_수의_합을_반환한다3() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 3);

	assertThat(sum).isEqualTo(5);
}

 

이런 사이클을 돌다보면 결국 진짜 구현을 만들게 된다는 생각이었다.

 

public class Calculator {

	public int sum(int n1, int n2) {
		return n1 + n2;
	}
}

 

하지만, 켄트 벡은 이러한 '진짜 구현을 만드는 것'조차 리팩터링의 과정으로 보고 있었다. 그 과정은 생각보다 세세하다. 아래는 그 과정을 나타낸 것이다. 정확하진 않을 수 있지만 나는 이렇게 받아들였다는 점을 알고 봐주면 좋을 것 같다.

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

public class Calculator {

	public int sum(int n1, int n2) {
		return 6;
	}
}

 

테스트 주도 개발에서는 리팩터링 과정에서 가장 강조하는건 '중복 제거'이다. 테스트와 Calculator 사이의 중복이 보이는가? 나도 처음엔 뭔가했지만, '6'이 바로 중복이다. 이를 켄트 벡은 중복이 테스트에 있는 데이터와 코드에 있는 데이터 사이에 존재한다고 표현한다. 그럼 이를 어떻게 개선할까?

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

public class Calculator {

	public int sum(int n1, int n2) {
		return 2 + 4;
	}
}

 

이렇게 6을 2 + 4로 바꾼다. 하지만, 여기서 또 재밌는 점은 2와 4도 중복이라는 점이다. 테스트 코드에 2, 4가 존재하기 때문이다. 그럼 먼저 2를 어디서 얻을 수 있는가? 'int n1'이다.

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

public class Calculator {

	public int sum(int n1, int n2) {
		return n1 + 4;
	}
}

 

상수를 인자로 대체했다. 그러면 다시 4가 남는다. 이 또한 중복이므로 같은 과정을 밟아 다음처럼 제거할 수 있을 것이다.

 

@Test
void 두_수의_합을_반환한다() {
	final var calculator = new Calculator();

	final var sum = calculator.sum(2, 4);

	assertThat(sum).isEqualTo(6);
}

public class Calculator {

    public int sum(int n1, int n2) {
		return n1 + n2;
	}
}

 

이러면 '진짜 구현'이 완성된다. 이 과정 자체가 되게 무의미 해보일 수도 있다. 하지만, 이런 세세한 구현 과정을 밟아나가는 능력을 강조하고 싶다. 지금은 예제가 되게 단순해서 시시할 수 있지만 어려운 요구사항 이었다고 생각해보자. 이러한 능력이 없다면, 아마 한 뭉텅이로 구현을 하게 될 것이고.. 결국 롤백의 과정을 많이 겪을 것이다. 하지만 이런 능력을 통해 문제를 좀 더 잘게 나누어 정복할 수 있다. 나는 이러한 점에서 테스트 주도 개발이 많은 도움이 되었다고 생각한다. 이러한 부분이 공감이 안간다면 아쉬운거지 뭐 어쩔 수 없다.

 

하지만 이렇게 강조해도 능력을 아는 것과 쓰는 것은 차이가 확실히 있다. 막상 구현하다보니 어디까지가 세세한 구현일까? 라는 고민도 되게 많이 했다. 그러다보니 꽤 오랜 시간이 걸리기도 했다.. 지속적으로 테스트 주도 개발을 풀어보는게 좋을 것 같다. 켄트 벡도 한 문제를 여러 번 풀어보는걸 추천하기도 했다. 매번 구현할때마다 다른 방식으로 만들어지는게 묘미라고 한다.

 

또 얘기할게 어떤 것이 있을까.. 아, 테스트 주도 개발을 통해 구현을 다 한 후에 애플리케이션의 실제 동작인 입력 - 출력의 기능들을 만들며 조립했는데, 예상했을 때와 다르게 실제 입력에서 에러가 발생하기도 했다. `\n` 이 개행문자가 문제였던 것인데, 테스트는 통과하는데 자꾸 실제 입력으로 처리하면 실패하는 그런 문제가 있었다. 그래서 꽤 애먹었던 기억이 난다.

 

또, 이게 green 과정 이후에 새로운 red 테스트를 작성해야 하는데 앞 단에서 구현한 것들 때문에 새롭게 작성한 red 테스트들이 바로 성공하는 경우도 있었다. 특히, 검증이 그랬다. 이런 경우에는 예외 메시지까지 테스트 통과 기준으로 삼아서 red 테스트를 만들기도 했다. 이 방식을 생각하기 전에는 `red-green` 이라는 커밋으로 하나 남겼는데, 이 부분은 좀 아쉽기도 하다. 이에 대해 claude도 한 소리 했다.

 

 

테스트 주도 개발은 '개발'을 위한 방법론이지만 개발자들의 사고 과정 자체를 바꿔준다는 점에서 되게 매력적이다. 또한, 이런 사고 과정 자체도 내게 되게 잘 맞는다고 느꼈다. 앞으로도 종종 이러한 문제나 실제 프로젝트에서도 테스트 주도 개발을 통해 쭉 이어나갈 것 같다. 다들 테스트 주도 개발의 매력을 느끼고 시도해봤으면 한다.