티스토리 뷰

Opinions

TDD 참관 후기

Voyager Woo 2018. 10. 24. 01:44
반응형

지난 10월 16일 오마이랩의 CTO 이규원님이 진행한는 TDD 참관에 참여했다. 내가 이 참관에서 가장 궁금했던 점은 실제 TDD 루틴을 확인하는 것이고 어떤 프로세스와 문화 안에서 작업을 하는가였다. 그리고 어디까지 TDD로 커버해야할까에 대한 힌트를 얻기를 기대했다. 만남이 끝나고 돌아오면서 생각해보니 많은 도움이 된거 같은 참관이었다. 그때 이야기 했던 내용들을 정리해볼까 한다.

RED GREEN REFACTOR

처음에 만나서 이야기를 시작하며 규원님이 TDD는 RED, GREEN, REFACTOR를 반복하는 것이라고 말씀을 해주셨다. 그러면서 RED, GREEN, REFACTOR가 무엇인지 여쭤보셨다. 그래서 TDD by Example에서 읽어서 알고 있던 이야기를 해보았다.

"우선 개발할 내용에 대해서 테스트를 먼저 구현하는데, 실패할 테스트를 간단하게 만들고 실패해서 빨간불을 먼저 봅니다. 그다음에 그 케이스를 성공할 만큼만 구현해서 초록불을 봅니다." 이를 반복하다 보면 코드들이 복잡해지는데 그것을 리펙토링 합니다. 테스트 코드도 리펙토링 합니다."

이렇게 질답을 한 이후에 18일에 있을 발표자료를 살짝 보여주시면서 이야기를 이어나갔다.

엔지니어로서 개발자

위 사진을 보면서 프로그래머는 엔지니어적인 부분이 크다고 말씀해주셨다. 즉, 아름답고 완벽하게 하는 것이 중요한것이 아니라 되게 하는 것이 중요한 것이다. 근본주의적으로 할 필요는 없다.

최근에 서버에서 지표수집기로 지표를 보내도록 설정하는 코드를 작성했었는데 이 부분은 테스트 코드로는 어떻게 작성할까 고민하고 있었다. 그 고민에 대해서 어느 정도 답이 되었다. TDD에 집착해서 시간버리느니 이런 내가 코드로 테스트하기 어려운 부분은 그냥 눈으로 손으로 테스트하고 할 수 있는 것을 TDD로 작성해보자.

최대한 서비스레이어를 두껍게

현대의 복잡한 백앤드 프로그램들은 대부분 레이어드 아키텍처로 구성되어 있다. 큰 단위로 살펴보면 가장 하부의 레이어는 인프라, DB, 외부 서비스 등을 연결하고 있고, 그 위에 비즈니스를 처리하는 서비스 레이어, 그리고 그 위에 흐름을 제어하고 외부와 연결된 컨트롤러 레이어가 있다. 외부에 공개되어 있는 가장 상위 레이어는 흐름만 제어하는 곳이므로 복잡해져서는 안된다. 저수준의 레이어에서는 외부 서비스 같은 개발자가 제어하기 힘든 것들이 많이 있다. 그래서 제어할 수 없는 곳을 얇게 만들고 우리가 제어할 수 있는 서비스 레이어를 두텁게 만들어야 한다.

한가지 더 첨언 하자면 DB 같은 하부 레이어에서 SQL처럼 표현력이 부족한 언어로 비즈니스 로직을 처리하는 것보다 서비스 레이어에서 표현력이 좋은 언어로 코드를 작성하는 것이 설계 측면(나중에 스케일 아웃), 유지보수 측면에서나 Observability 측면에서 압도적으로 낫다고 생각한다.

즉, TDD를 통해서 서비스 레이어를 개발하고 스스로 검증 가능한 소프트웨어를 작성해야하는 것이라고 이해했다.

가설 실험 검증

나도 자꾸 실수하는 부분이 바로 이 부분이다. 어느 순간 코딩이 편해져서 생각없이 코딩을 할 때가 있다. 정신없이 코딩을하고 나서 뒤돌아보면 많은 코드가 작성되어 있다. 그러나 그 직후에도 한눈에 들어오지 않고 나중에는 보고 싶지 않은 코드 무더기가 되어버린다. 가설, 실험, 검증에서 실험만 계속했던 것이다. 실험은 재미있지만 그 실험을 다시 해석하거나 유의미하게 재사용하기 쉽지 않다.

쪼개기

규원님이 일하는 과정은 가설, 실험, 검증 프로세스를 그대로 따르고 있었다. 요구사항을 유저스토리로 분석하고 그에 따라 테스크를 나누고 테스크에서 여러 단위테스트를 추출한다 그리고 테스트가 무엇을 검증해야하는지에 대해서도 가설을 세운다. 그 다음 테스트 코드를 작성함으로써 가설을 자동으로 검증할 수 있는 환경을 만든다. 그리고 코드를 작성함으로써 실험을 하고 작은 수준에서 계속 실험과 검증을 계속 한다. 충분히 작은 단위로 쪼개고 테스트하고 그렇게 만들어진 기능들을 차곡 차곡 쌓듯이 프로그래밍 한다고 느껴졌다.

TDD는 손이 먼저 나가서 테스트 코드를 작성하고 애플리케이션 코드를 작성하는 것이라고 생각했지만 이번에 그것이 아니라는 것을 깨닫게 되었다. 충분하게 분석하고 고민해서 작은 단위로 쪼개고 그리고 코드를 작성하는 것, 그 중요성을 실감했다.

[요구사항 분석] 1 ----> n [유저스토리] 1 ----> n [테스크] 1 ----> n [테스트 유닛]

TDD 시연

규원님이 현재 작성중이신 위키를 보여주셨다. 요구사항을 정리하고 분석한 문서였다. 이해하기 쉬운 다이어그램이 있고 그를 설명하는 글들이 있었다. 규원님은 어려운 것일 수록 잘 정리한다고 하셨다. 요구사항에서 유저 스토리를 추출했다. 그리고 유저 스토리를 통해서 테스크를 추출하고 테스트 케이스들에 대해서 미리 정리를 해두고 작업을 진행하였다. 해야할 커밋도 미리 계획했다. 커밋의 범위가 커지면 코드리뷰하기 어렵기 때문에 쪼개는 것이 중요하다.

계획한 대로 테스트 코드 작성을 먼저 시작했다. 테스트 코드는 비슷했던 테스트 케이스가 있어서 그것을 참조하여서 작성했다. 규원님은 Arrange, Act, Assert 과정이 있는 AAA 패턴으로 테스트 코드를 작성했다. 내가 기존에 알고 있던 GWT(Given, When, Then)과 이름은 달랐지만 거의 의미가 같다고 느꼈다. 검색을 좀 해보니 AAA 패턴은 자신의 코드 조각들을 테스트 하는데 유용하고 GWT 패턴은 비즈니스 환경에서 비즈니스 가치들을 테스트하는데 유용하다고 한다. 참고 링크 : https://softwareengineering.stackexchange.com/questions/308160/differences-between-given-when-then-gwt-and-arrange-act-assert-aaa

Arrange 부분에서는 전제 조건들을 준비하고 Act 부분에서 테스트할 부분을 실행하고 Assert 부분에서 원하는 값이 나왔는지 검증했다. 우선 빨간불을 먼저 확인하고 차근차근 초록불을 향해서 코드를 채워나갔다. Visual Studio의 라이브 테스트라는 도구를 통해서 쉽게 확인할 수 있었다. 그렇게 TDD 시연을 마쳤다.

진짜로 TDD를 통해서 서비스를 만들고 있었다. 개인적으로 인상깊었던 것은 이런 규원님의 방식을 주니어 개발자들이 카피해서 하고 있다는 것이었다. 역시 사람을 잘만나야...

강제된 프로세스

규원님은 github flow를 통해서 팀원들과 협업을 하고 있었다. 테스크 단위로 브랜치를 만들고 개발을 마치면 마스터로 풀리퀘스트를 생성한다. 테스트를 모두 통과하고 팀원 한명이 리뷰를 해야지 시스템에 의해서 마스터로 자동으로 머지가 된다. 내가 인상깊언던 점은 그 누구도 심지어 CTO인 규원님도 마스터 브랜치로 머지할 수 없는 것이었다. 무조건 테스트를 통과하고 리뷰를 통과해야한다.

집에 오는 길에 ‘그럼 핫픽스는 어떻게 할까?’ 라고 생각했다. 그러나 이것도 잘 생각해보니 멍청한 질문이다. 우선 급해도 테스트를 통과하고 리뷰를 해야한다. 그렇지 않으면 버그의 반복일 수 있다. 그런 경우를 자주 보기도 했고 경험하기도 했다.

개인적으로는 이런 프로세스의 강제가 주는 장점이 강제하지 않을 때보다 훨씬 큰듯하다. 처음에 이런 루틴이 답답하겠지만 익숙해진다면 테스트 코드에 익숙해 질 것이고 그렇게 만들어준 테스트들이 서비스를 지켜줄 것이다. 또한 리뷰를 통해서 개발팀이 상향평준화 될것이다. 처음에는 노력이 제법 필요하겠지만 익숙해지고 문화가 된다면 보다 안전하고 마음 편하게 개발하고 배포할 수 있을 것이다.

기술 리더들이 이런 프로세스를 잘 프로그래밍하는 것이 중요함을 실감했다.

나의 자세

수준 높은 회사의 문화와 코드를 직접 볼 수 있어서 너무 좋기도 하고 자극이 많이 되었다. 습관을 바꾸는 일이라 TDD는 아직까지도 쉽지 않다. 꾸준히 TDD를 수련해야겠다고 다짐했다. 좋은 기회를 주신 이규원님께 감사드리며 이글을 마친다.

참고: 최근에 개인적으로 좋았던 자료

스프링캠프 2013 TDD Live - 최범균

최근에 TDD에 대해서 다시 공부하면서 굉장히 도움이 많이 되었던 자료이다. 자바 개발자가 흔히 작성하는 스프링 기반의 웹 서버에서 인증 관련된 서비스를 라이브 코딩으로 보여준다. 라이브 코딩 자체도 좋았지만, 유닛 테스트 작성의 순서를 알려주어서 그 부분이 굉장히 유용했다.



반응형

'Opinions' 카테고리의 다른 글

서비스 분리시 고민할 점 - 이름 정하기  (0) 2019.12.21
좋은 개발자의 덕목 V2  (1) 2019.12.16
리팩토링을 하는 이유  (0) 2018.11.27
좋은 개발자의 덕목 세가지  (0) 2018.07.18
개발입문자 코드읽기 제안  (0) 2018.07.04
댓글
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함