TDD 읽은티내기
TDD 관련해서 모아놓은 8개의 링크를 읽어보고 티 좀 내보기로했다
요즘에는 테스트 코드를 작성하려고 의식적으로 노력한다. 테스트 코드를 작성하다보면 내가 제대로 하고 있는건가? 혹은 이게 정말 도움이되는 건가? 라는 생각을 하게된다. 남들은 어떤 생각을 할까? 정말 궁금하단 말이야.
언제 날 한 번 잡고 그날그날 프로그래밍에 올려둔 테스트 관련 글들을 다시 한 번 쭉 읽어봐야겠다라는 생각을 했고, 그게 바로 오늘이다. 자, 그래서 이제 읽어본 티좀 내련다.
아 참, 아마도 이 글은 책읽은티내기라는 얼토당토 않은 페이지에서 시작되었을 것이다. 굳이 이런 말을 꺼내는 것은 페이지 좋아요 해주었으면 좋기 때문... 이다.
Product Manager 관점에서 바라 본 TDD
기록:
개발자 입장에서 테스트 코드는 일종의 심리적 안전 장치로 작동한다. 이는 곧 개발자가 변경 요건 발생에 덜 민감, 변경 요건 발생에 더 열린 자세를 갖는데 큰 도움이 된다. 요건 변경에 대한 열린 자세는 곧 린하게, 애자일하게 일할 수 있는 바탕이 되며 프로덕트가 시장 니즈에 맞게 점진적으로 발전하는데 큰 도움이 된다.
하루하루 살얼음을 걸을지 초반 스피드는 늦더라도 빠르게 변화에 대응하는 안정적인 제품을 만들지. 선택은 자유다. 라는 마지막 말이 마음에 든다.
Front-End 프로젝트의 Test Code 작성 경험기
기록:
예전에 포스트하고 다시 읽었다. 테스트에 익숙하지 않을 때에 하는 고민들의 대부분 다루고 있고, 그에 대해 어떠한 식으로 해결하였는지, 어떠한 식으로 개선하였는지에 대해 설명하고 있어 좋다.
다시 자세하게 읽으니 아래 부분이 눈에 띄고 도움이 되었다.
1. 테스트 라이브러리 의존성을 낮추는 코드를 작성하라.
2. 래퍼 메서드는 래핑된 메서드의 called 만 체크하고 래핑된 메서드를 따로 테스트할 수 있도록 하라
3. 가짜 로컬 스토리지 테스트 부분
소소한 배민라이더스 BROS 2.0 오픈 이야기
기록:
JUnit의 한글 테스트 디스크립션 스크린샷이 마음에 들어서 보관해둔 링크를 다시 읽었다.
개인적으로 테스트 디스크립션을 작성할 때 습관적으로 '~해서는 안된다' 같은 부정문으로 작성하는 경향이 있는데 여기에서는 '예외가 발생해야 한다~' 같은 긍정문으로 작성하고 있는 것이 마음에 든다.
Swagger를 통한 api 문서 관리 쪽에서는 Swagger jsdoc 도 살펴봐야겠다는 생각을 했다.
유닛테스트에 대한 생각
기록:
이전에는 테스트 코드 작성할 시간이 없다고 생각하고 넘어갔는데, 조금조금 테스트 코드를 작성하다 보니 요즘에는 여기에 나오는 내용들의 거의 전부를 공감하고 있다.
'코드의 사용자 입장'을 언급하는 부분이 마음에 든다. 머릿속으로만 그리는 코드는 실제로 사용하려고 보면 인터페이스 등이 사용 패턴에 잘 맞지 않는 경우가 있다는 언급이 크게 공감된다.
'코드 작성 방식의 변화'에서는 오류를 어느 단계에서 처리할지가 더 명확해져서 좋다는 부분이 있는데, 바로 이 지점이 테스트 코드 작성하면서 제일 크게 도움되는 부분인 것 같다.
그 외에 글의 초입에 TDD와 유닛 테스트에 대한 의견을 적어주셨는데, 이 부분도 마음에 든다.
"그냥 코드를 작성하는 과정에서 테스트 코드를 작성하는 게 포함되어 있으므로 테스트가 먼저인지 나중인지는 크게 신경 쓰지 않는다."
TDD는 죽었는가
기록:
이건 늘 읽어야지 읽어야지 하는데 길어서 잘 안 읽게 된다. 역시 이번에도 다 읽지는 못했다.
페이스북 해커톤에서 절반은 TDD가 가능했으나 절반은 그렇지 않았다.라는 부분이 꽤 흥미로웠다. TDD를 하지 않은 절반이라고 테스트를 하지 않는 것은 아니고 TDD 스타일이 아닌 재발(regression) 테스트와 짧은 피드백 루프를 사용한다라고 언급하고 있다. TDD의 형태이든 아니든 어쨌든 테스트가 중요하다는 내용. 전반적으로 테스트는 필요하되 그 스타일을 어디까지 강제할 것인가에 대한 토론이라는 인상이다.
테알못 신입은 어떻게 테스트를 시작했을까?
기록:
1년 차 신입 개발자의 테스트에 관한 소회를 담은 슬라이드이다. 나는 1년 차에 뭘 했던가 하고 한탄했다.
29페이지의 나랑 다른 디스크립션 스타일이 흥미로웠고,
41페이지의 TDD가 집중력 향상에 도움이 된다라는 부분도 공감할 수 있었다.
테스트 코드를 짜다보면 코드에 의해 흥분(좋든 나쁘든)하게 되는 경우가 많이 줄어든다. 덕분에 집중력이 향상되기는 한데, 흥분에서 오는 재미가 줄어서 조금 아쉽기도 하다 ㅋ.ㅋ
의식적인 연습으로 TDD, 리팩토링 연습하기
기록:
요즘에는 나름 테스트 코드를 작성하려고 노력하고 있다. 개인적으로 테스트 코드 작성을 시작하는데 제일 먼저 닥치게 되는 어려움은 테스트 프레임워크의 메서드가 "손에 익지 않아서"이다. 마침 이름 의식적으로 연습하자는 제목의 슬라이드라 바로 읽어보았다.
내가 생각하는 것과는 다른 내용이긴 했지만 아주 좋은 내용들임은 확실하다. 이 슬라이드에서는 특히 자주 사용하는 API를 위주로, 예를 들어 array 에 요소를 push 한다던가 하는 부분 위주로 테스트를 의식적으로 연습하라는 부분이 크게 도움이 되었다. 비동기 부분 테스트를 조금 더 연습해야겠다는 생각이 들었다.
당신들의 TDD가 실패하는 이유
기록:
팀 기준으로 TDD가 실패하는 이유를 짚어 놓은 슬라이드인데,
TDD가 가능한 개발 문화가 자리 잡혀 있어야만 지속적이고 성공 가능한 TDD 가 된다라는 점이 내용이다.
같이 노력해야 하는 것이지 뭐 ㅋ.ㅋ 아무도 노력 안 할 때 혼자 노력하고 다른 사람들에게 전파할 수 있느냐고 한다면... 내겐 아직 어려울 것 같다.
---
테스트 코드가 정말 도움이 될까라는 부분에 대한 조심스러움으로 다시 읽어본 글들이다. 시간에 쫓겨서 힘들다고 생각하는 부분들도 있기는 한데, 일단 한 번 짜보면 느낌이 좀 달라진다. 확실히 내 코드에 안심이 되는 심리적인 측면이 있어서 만족스럽다.
어떻게 하다보면 코드 실력이 늘을까라는 생각을 많이 하는데 테스트 코드를 작성하면 자연스럽게 코드 실력이 늘어나는 쪽으로 행동하게 되는 것 같다. 여러모로 하는게 좋은 것 같다.
뭔가 좀 엉성한 끝맺음이네...!
---
그리고 잠깐... 초라하나 제 책과 페이지 구경 한 번씩만...!
