우아한 테크캠프 pro 회고 - 3주차

인수테스트...?

3주차는 ATDD (인수테스트 주도개발) 로 시작되었다.

1. 기존 실패하는 테스트 작성

2. 테스트 성공을 위한 구현

3. 리팩토링

의 절차로 이어지는 TDD에 인수테스트(Acceptance)테스트를 더한 것이

인수테스트의 기본 사이클이라 볼 수 있는데, 

쉽게 이해하자면 인수테스트로 결과적으로 나와야하는(리턴) 값이 무엇인지를 정의해둔다.

이를 테스트 코드로 구현한 인수테스트가 있을때, 내부의 로직 구현은 이 인수테스트가 성공하는

상황 아래에서(리턴값이 고정된 상태에서) TDD 사이클을 이용해 구현해 가는 방식이다.

(적어도 내가 이해한 바로는 그렇다.)

 

TDD 수업을 들으며 테스트 주도 개발 방식으로 잘 구현해 나가다가도 마지막에 각각 구현된 로직들을

합쳐서 돌아가는 프로그램을 구현하게 될 때, 로직간 객체를 통한 메시지를 보내는 방식이 어려워 지는 경우나

적절히 합치기 어렵게 상태값을 나눠 가지고 있는 경우 등 결국엔 어그러지는(?) 구현이 되어버리는 경우가 많았다.

 

그럴땐 억지로 테스트 코드를 변경하거나 다시 새로 짜야하는 수고가 발생하곤 했는데, 이런 경험들을 통해 마음 한켠에 TDD로 채우지 못하는 아쉬움 같은게 남아있었다.

 

그래서 인수테스트..!

그런데 이 인수테스트 주도 개발이라는 녀석이 그 아쉬움을 풀어줄 방안을 제시하고 있었다.

TDD 사이클 전에 큰 범위에서 인수테스트 라는 녀석을 작성하여 결과값을 고정시키고, 내부의 실제 구현은 TDD 사이클을 지켜가며 작성을 하는 방안이다. 이를 통해 코드를 짜게 되면, TDD만 할 때의 bottom - up (혹은 inside - out) 방식으로 구현하던 것들이 up - bottom (ouside - in) 방식으로 구현할 수 있게 된다. 

큰 구조를 잡아두고 내부를 채워가는 느낌의 개발방식이라 결과적으로 틀은 어그러지지 않게 된다.

TDD에서 아쉬웠던 점이 말끔히 해소되는 느낌이었다.

 

쉬운 리팩토링

리팩토링에도 너무 좋다. 큰 범위내에서 테스트 코드를 짜서 로직을 보호해 주니까 내부적으로 소소한 부분은 얼마든지 변경하더라도 이상이 없다. 다만, 결과값이 같다고 해서 항상 옳은 로직이라는 보장은 해줄 수 없다는 약간의(?) 단점이 존재한다.

결과값이 같으면 결국 같은거 아닌가? 하는 물음이 있을 수 있으나,

결과값 이외에도 내부적으로 유효성 검사나, 사이드 이펙트를 검증하지 않으면 안된다. 

이러한 부분은 TDD를 통해 작은 단위(메소드 정도의 작은 단위)의 코드까지 보호해 주게 되면 인수 테스트의 약한 부분을 보완해줄 수 있다. 결국 인수테스트 - TDD는 서로 상호작용하며, 안전하고 튼튼한(?) 코드를 설계할 수 있게 해준다.

 

그래서 ATDD는 완벽...?

3주차 회고가 약간은 ATDD 찬양글(?) 성격을 띄게 되었는데, 개인적으로 TDD에서 못 채웠던 부분을

말끔히 해소해준 고마운 개발방식이라서 그런것 같다. 하지만 이러한 인수테스트 주도 개발 방식도 '구슬이 서 말이라도 꿰어야 보배'라는 말처럼 실제 구현 능력이 떨어지면 아무 쓸모가 없다.

그런데, 이번 3주차부터는 구현하기가 까다로운 내용이 나오기 시작했다.

지하철 노선에서 구간을 조회하는 것이 그것인데, 처음에 헷갈린 부분은 구간의 아이디값은 구간이 이어진 순서대로 정해져 있는 줄 알았다. 그래서 추가나 제거 후 조회하는 로직에서 구간 아이디 값으로 정렬하게 되면 노선 내 구간 순서가 정렬될 줄 알았다. (그렇게 착각했다.) 하지만 이게 웬 일인지 조회된 내용을 보면 아이디 값으로는 정렬되지 않았다.

추가가 무조건 구간의 뒤쪽에 되는 것이 아니라 중간이나 앞으로도 될 수 있었기에 아이디 값을 통한 조회는 무의미 했던 것이다.  나중엔 이를 깨닫고 지하철역간의 연결 상태를 일일이 확인하여 현재 구간에서 가장 앞에 연결되어 있는 지하철역과 가장 마지막 지하철역을 구하고 중간의 지하철역들을 이어지게 하여 조회할 수 있었다.

 

배운점/회고

여러가지 개발방식이 존재한다. ATDD도 그 중 하나인데, 잘 사용하면 너무나도 좋은 개발 방식이다. 하지만, 아무리 좋은  개발 방식이더라도 구현을 못하면 의미가 없다는 점을 확실히 깨닫게 되었다. 결국 기본 개발/구현 능력을 탄탄히 다져야 겠다는 다짐을 해본다.