저는 BDD 수준으로 꼼꼼한 테스트를 작성할 게 아니라면

특히 단순 유닛 테스트 수준이라면 대체로 반대.

여기서 '대체로'는 쩌기 빅테크들이 만들어내는 대규모 프로젝트가 아닌

쩌리 개발자, 쩌리 회사들이 만들 소규모, 연매출 몇억 수준의 서비스라면 굳이...

TDD를 주창한 켄트 벡을 본 마틴 파울러는, 그가 코딩하는 동안 30초마다 테스트를 돌리는 걸 보고 감탄했으며, TDD는 압박과 TEST FAIL로 인한 스트레스를 줄여서 선순환시키는 정신적인 요소가 중요합니다. 켄트 벡의 저서인 테스트 주도 개발에 따르면, 테스트를 실제 코드보다 먼저 작성하는 등, 테스트를 하기 위한 여러 방법을 제시합니다. 저는 테스트가 프로그래밍에 있어서 품질적인 면을 고려할 때 필수불가결하기 때문에, 모든 프로젝트에서 TDD를 조금이라도 실천해야만 한다고 주장합니다.

덧붙여 말하자면 프레임워크를 학습하는 과정에서 기능의 작동을 테스트하는 것도 마찬가지로 대화식 프로그래밍으로써 좋다고 생각합니다.

개인적으로는 TDD를 포함한 여타 다른 기능에 직접적인 영향을 끼치지 않는 것들은

도입함에 있어 내 주제를 잘 알고 도입해야 한다고 생각합니다

당장 내일 뭔가를 만들어 내야하는데, 제 후배가 유닛 테스트 작성해서 테스트 하자는 의견을 낸다면 백이면 백 뒤통수부터 후리고 볼 것 같습니다.

프로그래머는 당면한 문제를 코드로 해결하는 사람입니다.

당면한 문제를 제한 조건 내에 해결할 수 있다면, 그 이외의 것들은 차순위로 고민해야 할 것들입니다.

TDD, BDD, DDD 와 같은 개발 플로우나 패러다임 등을 차용하는 건 그 모든 제한 조건이 해결된 상태에서나 가능한 일입니다.

매출 몇억 몇십억 단위의 프로젝트에서는, 테스트 같은건 있으나 없으나 퀄리티에 영향을 끼치지 않는데

(테스트가 없다고 퀄리티가 떨어질 수준의 프로젝트가 매출 몇십억밖에 안나오면 애초에 글러먹은 인력풀과 BM을 자랑하고 있다는 거임. 아예 시작조차 안하는게 이로움.)

테스트가 있으면 심지어 현실적인 문제마저 방해받기 시작합니다.

테스트를 작성하는데 들어가는 비용이 수작업으로 테스트하는데 들어가는 비용보다 저렴해지려면 그만큼 규모가 방대해져야 하고

테스트를 작성하는데 들어가는 시간이 수작업으로 테스트 하는데 들어가는 시간보다 덜 걸리려면 그만큼 미리 설계가 꼼꼼해져야 하고, 그건 곧 비용의 증대를 의미합니다.

개발자의 신념에서만 보면 TDD는 충분히 찬성할만한 친구지만, 그게 비즈니스의 영역으로 들어가면 웬만해선 찬성하기 힘들다 정도겠네요.

세상에는 매출 수백억 수천억씩 뽑아내는 회사의 개발자보다, 매출 수십억 수준의 개발자가 수십배는 더 많으므로

빅테크들의 개발자들이 할 수 있는 시각으로 봤다간 가랑이 찢어집니다

토론

저는 프로젝트 상황에 따라서 다르겠지만 저는 대체로 찬성.
단, 있으나 마나 한 테스트 코드를 작성 할 거라면 반대