TDD는 테스트 코드 > 실행 > 에러 > 리팩토링 > 성공 사이클임. 근데 TDD한다는 사람들은 실제로 TDD사이클로 하는게 아니라 걍 개발확인용으로 중간에 또는 개발끝나고 유닛테스트 코드를 만드는 경우가 많음. 근데 앞의 경우처럼 TDD를 "해야만 하는건 아니지". 다들 TDD한다고 말하면서 실제로는 유닛테스트만 만드는데 그걸 TDD한다고 말하는 것도 좀 이상하기도 하고..
w(125.191)2018-02-04 14:17
어차피 개취임. "뭐하려고 했지? 다음에 뭐 해야하지?" 이런식으로 멍때리거나 세세하게 테스트를 작성해야 하는 환경이면 TDD가 좋음. 반면 개발흐름을 떠올릴 수 있고 막힘없이 진행할 수 있으면 개발확인, 정상동작 근거를 위한 유닛테스트로 족함. 그런 개취에 해당하는 내용을 유닛테스트 코드를 작성하는 정도면서 TDD를 해야만 하는걸로 취급하거나, 무조건 선진적인 것으로 취급하는 것은 아무래도 좀 그렇지. 나 오늘 TDD함, 우리회사는 TDD함 이런식으로 광고하거나 떠들것도 아니고..
그럼 뭘로 함?
걍 개발부터 함 - return 0;
즈언통
TDD는 테스트 코드 > 실행 > 에러 > 리팩토링 > 성공 사이클임. 근데 TDD한다는 사람들은 실제로 TDD사이클로 하는게 아니라 걍 개발확인용으로 중간에 또는 개발끝나고 유닛테스트 코드를 만드는 경우가 많음. 근데 앞의 경우처럼 TDD를 "해야만 하는건 아니지". 다들 TDD한다고 말하면서 실제로는 유닛테스트만 만드는데 그걸 TDD한다고 말하는 것도 좀 이상하기도 하고..
어차피 개취임. "뭐하려고 했지? 다음에 뭐 해야하지?" 이런식으로 멍때리거나 세세하게 테스트를 작성해야 하는 환경이면 TDD가 좋음. 반면 개발흐름을 떠올릴 수 있고 막힘없이 진행할 수 있으면 개발확인, 정상동작 근거를 위한 유닛테스트로 족함. 그런 개취에 해당하는 내용을 유닛테스트 코드를 작성하는 정도면서 TDD를 해야만 하는걸로 취급하거나, 무조건 선진적인 것으로 취급하는 것은 아무래도 좀 그렇지. 나 오늘 TDD함, 우리회사는 TDD함 이런식으로 광고하거나 떠들것도 아니고..
ㄴ 누가 뭐래냐; - return 0;