Search
Duplicate

Test-Driven Development: By Example

1회차

시작일: 2022-03-29
상황: 완독
후기: 켄트벡 옹의 아재드립에 피식거리는 나 자신에게 실망하며 일주일을 보냈다.
내용이 명확하기보다는 뜬구름 잡듯이 애매모호한 표현들이 많아서 명석하지 않은 내 두뇌는 혼란함 디버프가 계속 생겼지만, 악으로 깡으로 버티며 1회독 완료. 흥미있는 부분들에 대해 포스팅을 진행한다. 실습 위주의 코딩(파이썬으로 실습하는 xUnit 챕터)은 생략하고 이론 위주의 내용을 포스팅한다. 최소 3회차까지는 정독을 해야 어느정도 이해하고 설명할 수 있을 것 같다.

정리 포스팅

Search
Test
테스트 주도 개발(Test-Driven Development)를 잘 하기 위한 수련 방법에 대해 해당 책의 저자 김창준 님은 무술의 수행 단계를 나누는 수파리에 빗대어 테스트 주도 개발 수련 방식을 구분한다.

참고: 수파리(守破離)란?

무술의 수행 단계를 가리키는 말로 각 단계는 다음과 같이 구분된다. 수: 규칙을 충실치 지키는 것 파: 그것을 깨트려 자기만의 방식을 찾는 것 리: 규칙이나 형에서 자유로워지는 것

수(守)

처음에 수행해볼 방식으로 다음과 같다.
•
간단하고 쉬운 문제들로 TDD를 시도한다.
•
테스트 통과 시점(초록불) 에서 다음 통과 시점까지의 주기를 짧게 가지도록 한다.
•
테스트 통과시점 간의 최대 시간을 정해놓고, 이 시간을 초과하면 직전 상태로 롤백한 뒤 다시 시작하는게 좋다.
•
진짜로 만들기 전까지만 가짜로 구현하기를 적극적으로 사용하자. 테스트 통과 시점간의 거리를 좁히는 가장 간단하고 빠른 방법이다.
•
같은 문제를 여러번 풀어 보자.
•
처음에는 리팩토링 툴같은 자동화 도구를 사용하지 말자. 초보가 연습할 수 있는 순서나 과정을 생략하게 될 수 있다.

파(破)

•
테스트를 작성함에 있어 여유를 가지도록 하자. 정신없이 조급하게 프로그래밍을 할 필요 없다.
•
메타인식(meta-cognition)을 통해 내가 하는 것을 관조하고 기록하여 분석하자. 학습과 개선의 필수요소이다.
TDD 수련법

목차

TDD란?

Test-Driven Development 혹은 Test First Development + Refactoring
흔히들 테스트 주도 개발을 선후 관계없이 테스트만 작성하면 TDD로 알고 있는 사람과, 단위테스트는 TDD다 정도로만 알고 있는 사람이 많다. 책에서는 다음과 같이 TDD를 설명하고 있다.
TDD란 프로그래밍 의사결정과 피드백 사이의 간극을 의식하고 이를 제어하는 기술
TDD는 테스트 기술이 아닌 분석기술이자 설계 기술
이를 내 지식선에서 좀 더 쉽게 정리해보자면, 기능 개발에 앞서 기능을 가정하고, 그 가정에 대한 테스트를 작성하며 테스트가 통과하도록 만들고, 이를 개선하는 짧은 간격으로 반복하는 것을 TDD라고 생각한다.
그럼 이런 방식이 어떠한 장점이 있을까? 그냥 바로 기능부터 구현하면 생산성이 더 높아지지 않을까 생각할 수 있다. 하지만, OOP 패러다임을 기억하고 있다면, 객체간에는 메세지만을 주고받도록 설계하고, 각각의 객체간의 결합도를 낮추고 응집도를 높혀야 한다는 것을 기억할 것이다.
테스트 코드의 선행 작성은 이런 부분에서 하나의 기능에 대해 의존성을 파악하기가 쉽다.
특정 도메인의 기능을 테스트하려 할 때 이 도메인이 의존하고 있는 다른 객체가 많을 수록, 필요로 하는 매개변수 로직이 많아질수록 테스트는 힘들어질 것이다. 위에서 말했듯이 TDD의 핵심은 짦은 간격의 테스트 사이클을 반복하는 것인데, 이렇게 테스트 작성의 간격을 넓힉게 되는 코드를 만난다면 해당 코드가 어떠한 문제가 있다는 것을 알 수 있다. 그리고 이런 지점을 빨리 파악 할 수록, 완성도있는 코드로 도달하는 시간은 짧아질 수 있다.

TDD 사이클

TDD 개론, 간단한 예제

목차

개요

이번 포스팅에서는 몇 가지의 TDD 트릭, 몇 가지의 디자인 패턴, 몇 가지의 리팩토링을 소개하며
TDD를 좀 더 유연하고 잘 사용할 수 있도록 돕는 기술들에 대해 소개한다.

1. 빨간 막대 패턴

테스트를 언제 어디에 작성할 것인지와 언제 테스트 작성을 멈출지에 대한 내용.

1-1. 한 단계 테스트

내가 무엇을 테스트할 지 어떤 기준으로 선택을 할 것인가?
최종 목표로 한 단계 진전시켜줄 수 있는 테스트
사실 무엇을 테스트 할 지에 대한 선택에 정답은 없다. 사람마다 생각할 수 있는 바운더리가 다르고, 경험에따라 한 단계의 크기가 다를 수 있다. 내가 자동차라는 객체에서 전진, 후진, 좌회전, 우회전 4개의 테스트를 생각했다고 할 때 나보다 풍부한 경험을 가진 개발자는 여기서 기어 변속, 네비게이션 변경, 주유하기, 다른 기름 넣어 주유하기 등 더 많은 테스트를 떠올릴 수 있을 것이다.
TDD Pattern

목차

개요

테스트에 대한 지식이나 방법을 텍스트로만 접해서는 한계가 있고, 아직 감이 오지 않을 수 있다.
해당 포스팅은 켄트벡 옹의 저서 TDDBE를 기반으로 화폐 예제를 직접 테스트에 의해 주도되는 코드를 작성하고 기능을 개발할 것이다.
이번 포스팅을 보는 사람들은 TDD의 리듬을 파악할 수 있기를 바란다.

간략하게 보는 TDD 사이클

1.
테스트를 작성한다.
2.
모든 테스트를 실행 후 새로 추가한 테스트가 실패하는지 확인한다.
3.
코드를 조금 바꾼다.
4.
모든 테스트를 실행하고 모두 성공하는지 확인한다.
5.
리팩토링을 통해 중복을 제거한다.
TDD 화폐예제를 통한 테스트 실습
Made with