Home

Welcome to the tdd-challenge wiki!

Test-Driven Development : By Example

2023-09-07 (서문, 1장 ~51p)

• 이세명
  • 빨강, 초록, 그리고 리팩토링. 무엇이든 먼저 시작하고, 시행착오를 거치며 개선해나가는 과정이 살면서 마주칠 수 있는 많은 문제의 해결과정과 비슷하지 않을까 하는 생각이 든다.
• 정다현
  • TDD를 내가 익혔는가? 라고 하면 아닌 것 같았는데, 책에서 TDD 수련법을 소개해줘서 따라해보고 싶다는 생각이 들었습니다. 이제까지 1) 간단하고 쉬운 문제로 시도 하는 연습을 했다면 2) 작은 어플리케이션 하나를 TDD로 완성해보는 것 도 재밌을 것 같아요! 2) 과정을 거쳐야 TDD가 왜 좋은 지 와닿을 것 같다는 생각이 들었습니다.
• 최다인
  • 한국어판 인터뷰에서 아래와 같은 말이 나왔는데 충격이었다.
    내가 아직 기술이 부족해서 테스트를 작성하지 못하는 것일 뿐 모든 것을 테스트할 수 있다는 것에 공부할 것이 많음을 느꼈다.

  최근에 만델브로트(Mandelbrot) 브라우저를 프로그래밍했는데, 픽셀 하나에 대해서는 테스트를 작성할 수 없다고 생각했습니다. 이제는 그런 테스트를 작성할 수 있다는 것을 깨달았으며 (생략)

• 한지원
  • 테스트코드 없이 개발을 하며 느꼈던 문제 들이 TDD를 통해 어느정도 해결 될 수 있을 것 같다는 확신을 심어주는 드는 파트였습니다. 처음 챌린지를 할 때 테스트코드와 친해지기 위해 했던 과제들이 이 책의 과정에 더 몰입하게 만들어 주고있다는 생각도 들었습니다.

2023-09-14 (52p ~ 112p)

• 이세명
  • TDD란 조종해나가는 과정이다!
• 정다현
  • OOP를 공부하는 느낌이었네요.. 리팩토링 과정에서 달라진 인터페이스를 반영해서 어떻게 테스트 코드를 수정해나가는지 알아볼 수 있었습니다!
  • 예시 코드가 자바라서 이해가 어렵네요 ㅠㅠ 자바스크립트로 예시 코드를 같이 구현해보면서 공부해보는 건 어떨까요!
• 최다인
  • 삼각측량 전략이라는 익숙하지만 추상적이었던 방식을 명시해주어서, 앞으로 의식적으로 사용할 수 있을 것 같다.
  • 11장 까지의 예제에서 상속 관계의 클래스를 만들었다가 제거되는 과정에서, 아키텍처 주도 개발(architecture-driven develop)과 정 반대라는 말을 실감했다. 테스트를 작성하고 통과시키는 과정에서 아키텍처는 자연스럽게 따라오는 것이 인상적이다.
  • 켄트 백의 급발진 포인트들이 너무 재미있다.🤣

    팀으로 돌아가서, "켄트가 설계 어쩌구 하는 것은 모조리 중요하지 않다고 했다."고 전할지 모르겠다. 멈춰라.

• 한지원
  • 예시가 자바라 조금 어색했지만 저자의 코드를 순차적으로 따라하면서 TDD에 대한 감이 잡혀갔습니다.

2024-01-09 (113p ~ 157p)

• 이세명
  • 저자가 작성한 메타포가 이해하기 어려웠다. TDD를 위한 기능은 아닌 것 같았지만 새로운 패러다임을 익힌 느낌이었다.
  • 원문의 언어와 우리가 구현하는 언어의 차이로 인한 추가적인 공부가 더 필요할 것 같다.
  • 테스트 코드를 망치고 그게 돌아가면 TDD는 성공한걸까? 🤭
• 한지원
  • 14장: 리팩토링 과정에 테스트코드를 통해 실수를 발견하고, 그것을 바로 고치는 것이 아니라 관련된 또 다른 테스트코드를 추가하여 그것을 to do list처럼 활용한 과정이 인상깊었다.
  • 15장: 작업을 하나씩 해결하는 과정에서 우선 일반화를 시키고 컴파일러의 에러메시지에 따라 점진적으로 전체 영역을 수정해 나가는 방식이 나왔는데, 이전 장의 내용고 더불어 문제를 해결하는 방식이 여러가지라는 것을 체감했다.
  • 16장: 그동안은 저자가 TDD를 진행하는 과정에 집중해서 따라했었는데, 이 장에서는 경제적으로 TDD를 진행하고 있는지와 제대로 진행되고 있는지에 대해 생각해볼 수 있는 내용을 다루었다.
  • 17장: 그동안 해왔던 과정들이 요약되어있었는데 저자가 각 장에서 어떤 의미를 전달하고자했는지, 뭘 배우고 뭘 놓쳤는지 생각할 수 있었다. 또 TDD의 부산물로 나온 테스트코드가 성능과 사용성테스트 등 유지보수 그 이상의 기능까지 해줄것이라고 예상하지말라는 말이 가장 와닿았다.
• 최다인
  • 12장: 다중 통화 연산을 구현할 때 나는 머리에 저자가 처음 말한 참조 통화 방법을 떠올렸는데, 이게 어려운 방식이라며 새로운 방법을 제안한 것이 인상깊은 챕터였다.
  • 13장: 유익하다. 여러 클래스 객체들에 대해 동일한 연산을 구현할 때, 각 클래스별로 대응하는 코드를 작성하는 대신, 다형성을 사용하여 각 클래스 내부적으로 구현을 맞춰주어 코드를 줄인 부분이 유익했다. 실무에서 충분히 적용해볼 수 있을 것 같다. 그리고 요즘 IDE에서는 함수들 트래킹이 잘 되어서 전혀 느끼지 못했는데, 키워드 매개 변수를 지원하는 언어(python 등)가 아닌 위치 매개 변수를 사용하는 언어는 그 의도를 전달하기 어려울 수 있다는 것을 새삼 느꼈다.
  • 14장: 통화에 대한 환율을 저장하는 객체를 태스트 할 때, JUnit 테스트 코드에서 객체의 프로퍼티 값 동일성을 확인해주지 않아 equals를 별도로 구현했는데, Vite나 Jest에서는 toMatchObject등을 제공하여 쉽게 작성가능할 것 같다. 환율에 관한 해시테이블을 구현하는 부분이 신기했다.
  • 15장: Composite Pattern 이라는 말이 나왔다. 개발에서도 자주 듣는 말인데 Composite, Factory 등 자주 사용되는 디자인 패턴을 알아보아야 할 듯 하다.
  • 16장: 문서로서 테스트코드의 중요성에 관한 내용이 나왔다. 테스트코드는 기능을 빠짐없이 테스트하고 검증해야하지만, 더불어 테스트코드를 통해 다른 개발자들이 코드에 대해 잘 이해할 수 있도록 작성되어야한다. 예제에 클래스가 많아지고 각 클래스에 동일한 메서드가 구현되고 있는데 책의 코드만봐서는 그 흐름을 이해하기 어려운 것 같다. 스터디에서 직접 작성해보아야겠다.
  • 17장: 지금까지 진행한 Money 예제의 회고이다. Money예제에서 아직 완성되지 않은 부분도 정리하는데, 추가로 진행해보는 것도 좋을 것 같다. JUnit의 실행 로그를 통해 테스트코드를 작성하는데 걸린 시간을 분석한 부분도 재미있었다. 테스트코드와 실제 코드의 비율이 유사한 점도 재미있는 결과인 것 같다. 우리가 Typescript로 번역한 최종 코드에서도 통계를 내보면 좋을 것 같다.

  테스트 커버리지를 향상시키는 또다른 방법은 테스트의 수는 그대로 두면서 프로그램의 로직을 단순화하는 것이다.