TDD를 배우고 경험해보며 쌓아가는 이야기

요즘 회사에서 갑자기! Java 언어를 쓰고 있고 갑자기! SpringBoot 개발을 하고 있고 갑자기! TDD 기반의 개발을 하고 있다.

 

세가지 모두 학교다니면서 개발하던 내내 접하지 않았던 것들이라,, 근 2개월동안 스트레스도 많이 받고 우울해했다.

그래도 나름의 고난의 시간을 겪고 나니 하나둘씩 이해하고 있고, 아직은 팀원들의 코드를 복붙해서 재생산할 뿐이지만 적응해 가고 있다.

 

그래서 오랜만에 올리는 포스트로는 현재 우리 플젝에서 TDD를 어떻게 써 나가고 있는지,내가 프로젝트에 적응해가면서 어떤 점을 느꼈는지를 서술할 생각이다. 또한 현재 하고 있는 고민도 함께!

 

언제나 그랬듯이 이는 미래에 모든것을 까먹을 나를 위한 기록이다.

 

TDD 적용 현황

현재 우리 프로젝트는 변화를 거듭하며 (아직도) 성장중이고, 내가 글을 쓰는 지금 시점의 TDD 적용은 아래와 같은 구조로 흘러간다.

 

가령 Apple class를 개발한다고 해 보면,

1. Apple class가 나중에 생성되어 위치할 패키지 경로 그대로, Test 패키지 하위에 TestApple class 껍데기를 생성한다.

2. TestApple class와 같은 패키지에 AppleTest 테스트 클래스를 생성한다.

3. AppleTest에 요구사항을 만족하는 Test 코드를 짠다. (테스트 돌리면 실패는 당연하고 컴파일조차 안된다)

4. Test 코드를 통과하도록 TestApple class에 코드를 짠다.

5. 모든 테스트를 통과하면, src 하위에 있는 Apple class에 test 하위에 있는 TestApple의 코드를 적용한다.

 

나는 이 구조를 이해하고 실천하기까지! 무려 2개월이 걸렸다. (심지어 그 실천 오늘부터 함 2023-03-20)

그동안 나의 거지같은 코드와 쓰레기 커밋을 확인하셨을 팀원분들에게 죄송한 마음을 익명으로 보내드린다,,

 

오늘 갑자기 저녁에 야근하면서 아주 짧고 간단한 함수 하나를 (처음으로) 위의 TDD 방식을 그대로 적용하여 개발해봤다.

 

짱재밌음.

 

TDD 방식으로 (아주조금) 개발을 해 보면서 내가 느낀 장점은 다음과 같다.

1. 비즈니스 로직을 개발하다가 길을 잃었을 때(뭐해야하더라?, 나 뭐하고 있었지? 등) 나의 현위치를 파악하고 목표를 다잡기가 쉽다.

2. 어쩌다가 예전에 이미 만들어둔 로직을 수정해야 할 때, 기존 비즈니스 로직을 모두 만족하는지 전전긍긍할 필요가 없다. 기존 테스트 싹 다 돌려보고 통과하는거 확인하면 검증이 된 거니까!

3. 다른 사람이 짠 코드를 이해하기가 쉽다. 개인적으로 테스트코드의 given-when-then 구조가 사람이 사람에게 소스코드 설명할때의 구조와 정확히 일치한다고 생각하는 편이라, 테스트코드가 나한테 비즈니스로직을 설명해주는 기분이다.

 

장점만 있으면 재미없으니까.. 단점도

1. TDD 모르면 이해 못하고 아~대충 이건가? 완벽히 이해했어^^(아님)! 짤 나도 모르는 사이에 달고 있기 쉽다. 다른 사람이 짠 테스트코드만 봤을때는 뭐야 나도 짜겠다! 싶은데, 막상 TDD를 기반으로 개발하려고 new TestClass를 파게 되면 뭐부터 적어야할지 감이 안온다.

2. 기존 코드들을 일단 "테스트가 다 통과된 완벽한 놈들"이라고 신뢰하고 들어가기 때문에, 작은 것을 개발할때 확실하게 짜놔야 한다. 나중에 큰것을 개발할 때 그저 작은것을 call 해서 사용하는 경우라면, 작은 것은 무조건 요구사항을 만족하는 것을 보장한다고 가정하기 때문이다.

 

아무튼 오늘 야근하면서 고작 함수 두개 짜고 왔지만, TDD 방식으로 짠 것 같아서 좀 뿌듯하고 기분좋아서 포스팅 남기는중.

 

요즘 나의 고민

Test 함수명을 어떻게 해야 내마음에 들고 다른사람도 명확하게 볼 수 있을까?

class CalculatorTest{

    @Nested
    @DisplayName("add 테스트")
    class addTest{

        @Test
        void 어쩌구저쩌구() {
        }

    }
    
    @Nested
    @DisplayName("minus 테스트")
    class minusTest{
    
    	@Test
        void 어쩌구저쩌구() {
        }
    }
}

일단 우리는 어떤 함수를 테스트할 때 위와 같은 구조를 사용하고 있다.

 

보통 테스트함수명으로 given_어쩌구_when_어쩌구_then_어쩌구 로 테스트를 한눈에 보기 쉽도록 적는다고 하던데,

나는 일단 저 구조에서 displayName이 when_어쩌구의 역할을 하고있다고 생각해서.. given_어쩌구_then_어쩌구 로 적는 중이다.

 

근데 갑자기 생각난게 우리 프로젝트가 카멜케이스를 원칙으로 하고 있는데, 나처럼 given_어쩌구_then_어쩌구로 쓰면 스네이크 케이스 아닌감? 핫쉬 그렇다고 given어쩌구then어쩌구로 쓰면.. (개인적으로) 가독성 떨어진다고 생각하는데ㅠ 규칙은 규칙이니 내일 출근해서 rename 해야겠다.

 

---

뭔가 더 알차게 쓰고 싶은데 자야할 것 같아서 이만..

일주일에 하나씩 포스트를 써보겠어용 내일의 나 화이팅.