북 클럽: "테스트 주도 개발: 예제로"#13

13장: 만들다

이전에는 실제 논리를 사용하는 대신 테스트가 통과하기를 원하는 값을 반환하는 가짜 코드를 작성했습니다. 이 가짜 구현을 제거하기 위해 테스트를 사용하여 실제 구현으로 이동했지만 유지하고 싶지 않은 테스트입니다.

테스트는 우리가 원하는 코드 작성을 돕기 위한 목적으로만 구현을 테스트하기 때문입니다.

테스트를 알고 있다면 구현이 아닌 동작을 테스트한다는 것을 이미 알고 있습니다. 예를 들어 모양 공장을 사용하여 이것을 설명하기 위해 훌륭한 이야기를 했습니다.
정사각형 공장에서 만든 정사각형을 확인하는 테스트를 작성하는 경우 좋은 테스트는 정사각형의 변이 4개이고 모든 변의 길이가 같다는 것입니다. 정사각형 공장이 직사각형 공장에 작업의 일부를 아웃소싱하는 경우 정사각형도 두 개의 직사각형으로 구성되는지 테스트할 수 있습니다. 하지만 그것은 나쁜 테스트입니다. 통과하더라도 향후 아웃소싱을 삼각형 공장으로 전환하면 테스트가 실패할 것이기 때문입니다. 정사각형이 직사각형인지 삼각형인지는 신경쓰지 않습니다.

이 장에서 발생하는 또 다른 일은 유형의 캐스팅과 instanceof로 검사한 다음 리팩터링되는 것입니다. Beck은 Java의 한계에 대해 다음과 같이 말합니다.

Bank.reduce(Expression, String)
Expression.reduce(String)

...그는 키워드 매개변수가 있는 언어에서는 문제가 되지 않는다고 말합니다. 두 클래스의 메소드 이름은 동일하지만 매개변수는 다릅니다. 저는 키워드 매개변수에 익숙하지 않습니다. 여기 계신 분은 경험이 있으신가요?

🔎 https://github.com/ruthmoog/test-driven-development-by-example에서 내 코드와 함께 저장소 보기


Kent Beck의 "Test Driven Development: By Example"은 2002년에 발표되었습니다. 이 책은 TDD를 사용하여 작동하는 고품질 코드를 작성하는 방법을 설명하는 것을 목표로 합니다.