TDD는 작은 필요(Test-first)에 의해서


고립된 테스트로 짧은 피드백을 지속하며 개발하자는 컨셉임


그래서 코드 테스트 모두 변경에 ㅈㄴ게 강하고 유지보수가 쉽고 협업에 좋음


반면 유닛테스트는 오로지 기대 결과를 확인하는게 목적임


= 보통은 TDD 한다는 말이 유닛테스트를 해벌인다는 말임 ㅅ발 미쳐벌임 ㅋ



그렇다면 구구단이 외 TDD에 좋을까?


직접 구구단을 구현하고 테스트를 구현했다고 치자


테스트 코드가 어떤 모양으로 나올지 생각해봐 10초줌 






생각해벌임?




계산식 바꾸면 테스트 에러가 어디로 떨어짐?


출력 메커니즘을 바꾸면 테스트 에러가 어디로 떨어짐?


Row 스타일 또는 Column 스타일을 바꾸면 테스트 에러가 어디로 떨어짐?


2명이서 개발 가능함? 



가축이하 수준이면 모든 에러가 1개의 테스트로 떨어질거고


ㅈ밥 수준이면 2-3개 정도의 테스트에 에러가 떨어지겠지


ㅇㅇ 그게 본인 수준임 


구구단 정도의 단순한 걸로


코드를 고립시키는 능력과 추상/구현을 분리하는 능력이 딱 그 정도




으아아니 ㅅ발 그렇게 변경될거면 테스트 그렇게 안짜지?


ㅈㄴ 그 마음 이해함. 근데 현실에서도 앞으로 변경될 내용 모르잖아?


그보다도 애초에 TDD 했으면 계산과 출력이 결합된 테스트는 나올리 없음 ㅎ



구구단 쉬운데 막상 구현시키면


계산 로직에 출력 로직이랑 출력코드가 뒤섞인걸 만들고


최종결과만 assert 하는 테스트 1개 그린바 띄우고 조또없네 구구단~ 읔ㅋ 이럼


구구단 TDD를 말하면 테스트 1개를 상상해벌임 


으악 ㅅ발 유닛테스트는 TDD가 아니라고!! 



솔까 구구단으로 고립된 테스트들을 슴풍슴풍 못만들면서


복잡한 문제의 문맥을 이해해서 문제나 해답을 고립시킬 수 있음?


불가능하다 이기야


TDD by Example 예제가 Money 임. 쉬운걸로 TDD 하는게 낳다




만물구구단설.jpg