카테고리 보관물: 일반

코딩 시험과 TDD

구직 과정에 코딩 시험이 있었다. 면접관의 컴퓨터와 응사자의 컴퓨터가 코딩 시험 도구로 연결되어 면접관이 응시자의 코딩을 지켜보거나 개입할 수 있는 환경이었다. 어떤 문제의 답 코드를 쓰다 10줄 이상이 되니 자신감이 떨어져 TDD를 사용하기로 했다. 여기서 나는 흥미로운 경험을 했다.

물론 코딩 시험에 테스팅 도구는 주어지지 않았다. TDD는 테스팅 도구가 있어야만 할 수 있는 것이 아니다.

이 글에서 테스트 케이스는 테스트 코드가 아니라 테스트 데이터를 의미한다.

계속 읽기

소프트웨어 테스팅의 False Positive

False Positive는 이진 분류(binary classification) 실험 오류 중 하나로 통계 실험에서는 1종 오류(Type I Error)라고도 부르며 소프트웨어 테스팅에서도 쓰이는 용어다. 하지만 이진 분류와 통계 실험에 대한 배경지식이 없는 경우 소프트웨어 테스팅의 False Positive는 본래의 뜻과 반대의 의미로 잘 못 사용되곤 한다. 언어가 잘 못 사용되면 당연히 의사소통 장애로 이어진다.

계속 읽기

TDD가 해결해 주는 것들

2014년에 DHH는 ‘TDD is dead. Long live testing.’이라는, 제목이 아니라 내용이, 다소 황당한 글을 썼고 얼마 후 Kent Beck은 관련된 글을 썼다.

RIP TDD

DHH가 TDD를 죽여서 TDD를 대신할 방법을 찾아야 한다는 글인데, 제대로 읽었다면 누구도 이것이 Kent Beck이 TDD를 떠난다고 말하는 글이라고는 생각하지 않을 것이다. 내 가설의 증거는 댓글들이다. 재미있으니 댓글들도 한 번 읽어보기를 추천한다.

그럼 실제 내용은 뭘까? 프로그래머가 TDD를 통해 얻을 수 있는 가치의 나열이 대부분이고 나머지 조금은 DHH에 대한 조롱이다. 나는 여기에 나열된 TDD의 효과 모두를 느껴왔고 그래서 TDD를 사용한다. 그리고 이 가치들이 더욱 알려지기를 바라는 마음에 한국어로 번역했다. 내 영어 실력은 아주 형편 없어서, 노력했지만 두 구절은 충분히 이해하지 못해 직역했다. 표시해 뒀으니 좋은 해석 의견이 있다면 대환영이다. 이후로는 모두 내 글이 아니라 번역이다.

계속 읽기

Visual Studio Code를 사용해 Git 커밋 메시지 작성하기

많은 팀이 그렇듯 지금 일하는 팀 역시 소스 관리를 위해 Git을 사용한다. 난 커밋 메시지를 중요하게 생각한다. 코드는 쓰는 것보다 읽는 것이 중요하다. 코드 자체에 의도를 담는 것이 최선이지만 코드를 통해 동작을 표현하기는 쉬운 반면 코드의 작성과 변경의 이유는 표현하기 어려운데 커밋 메시지는 좋은 대안이다. GitHub의 Blame이나 Visual Studio의 CodeLens는 코드 읽기를 도와주는 강력한 도구이지만 이 역시 충실히 작성된 커밋 메시지가 뒷받침되어야 한다. 우리 팀은 양질의 커밋 메시지를 작성하려는 노력의 일환으로 ’50/72 규칙’을 사용한다. 그런데 우리는 한글과 관련된 문제를 발견했다.

계속 읽기

그게 통합 테스트라고? 정말?

글을 시작하며 우선 참회한다. 나는 오래 전 mockist였다.

당시의 나를 비롯해 mockist들은 단위 테스팅에 많은 테스트 대역(test double)을 등장시키고 그래야만 단위 테스팅이며 그렇지 않으면 통합 테스팅이라고 주장한다. 하지만 미안, 난 이제 변절자야.

계속 읽기

테스트 주도 개발 실천

테스트 주도 개발 실천

테스트 주도 개발(test-driven development)은 점진적으로 검증하며 코드를 작성하는 소프트웨어 개발 방법이다. 자신이 작성한 코드의 동작을 직접 확인하는 것은 어쩌면 프로그래머의 기본 미덕이고 테스트 주도 개발은 이 미덕의 실천을 프로그래밍 과정 속에 자연스레 녹여낸다. 또한 테스트 주도 개발은 좋은 설계의 강력한 지원자다. 테스트 주도 개발 자체가 좋은 설계를 유도하는 것은 아니지만 프로그래머가 좋은 설계를 위해 노력할 수 있도록 든든히 뒷받침한다.

하지만 테스트 주도 개발은 어렵다. 전통적인 프로그래밍 절차와 상이할 뿐 아니라 긴 시간동안 몸에 밴 나쁜 버릇들이 억제되며 답답함이 느껴지기도 한다. 개념을 이해했다 하더라도 현장에서 실천하는 데에는 많은 장벽들이 있다. 이 글은 가상의 예제가 아니라 간단하지만 실제 서비스 개발에 사용된 사례를 통해 현장에서 테스트 주도 개발이 어떻게 적용되는지 보여준다.

계속 읽기

비공개 메서드를 테스트 해야 하는가?

TDD(Test-Driven Development, 테스트 주도 개발)에 익숙하지 않은, 개체지향 프로그래밍 언어를 사용하는, 프로그래머들은 간혹 이런 질문을 한다.

비공개(private) 메서드도 테스트 해야 하는가?

이 질문의 대답은 ‘그렇다’ 또는 ‘아니다’보다 좀 더 길다. 비공개 메서드의 인터페이스는 테스트 하지 않지만 비공개 메서드의 구현은 테스트 대상이다. 혼란스러울 수 있다. 어쩌라는 말인가?

계속 읽기