[unit-testing] 테스트 주도 개발의 단점? [닫은]

몇 년 동안 테스트 중심 개발을 수행해 왔지만 가장 큰 단점은 다음과 같습니다.

경영진에게 판매

TDD는 쌍으로 수행하는 것이 가장 좋습니다. 예를 들어 if / else 문 을 작성하는 방법을 알고 있을 때 구현을 작성하려는 충동에 저항하기가 어렵습니다 . 그러나 당신이 그를 계속 임무로 유지하기 때문에 한 쌍은 당신을 임무에 계속합니다. 안타깝게도 많은 회사 / 관리자는 이것이 리소스를 잘 사용한다고 생각하지 않습니다. 동시에 수행해야하는 두 가지 기능이있을 때 두 사람이 하나의 기능을 작성하도록 비용을 지불해야하는 이유는 무엇입니까?

다른 개발자에게 판매

일부 사람들은 단위 테스트 작성에 대한 인내심이 없습니다. 일부는 그들의 일을 매우 자랑스럽게 생각합니다. 또는 복잡한 방법 / 기능이 화면 끝에서 번지는 것을 보는 것과 같습니다. TDD는 모든 사람을위한 것이 아니지만 실제로 그렇게 되었으면합니다. 코드를 물려받은 불쌍한 영혼을 위해 물건을 훨씬 쉽게 유지 관리 할 수 ​​있습니다.

프로덕션 코드와 함께 테스트 코드 유지

이상적으로 코드를 잘못 판단 할 때만 테스트가 중단됩니다. 즉, 시스템이 한 방향으로 작동한다고 생각했지만 그렇지 않은 것으로 나타났습니다. 테스트 또는 (작은) 테스트를 중단하면 실제로 좋은 소식입니다. 새 코드가 시스템에 어떤 영향을 미치는지 정확히 알고 있습니다. 그러나 테스트가 제대로 작성되지 않았거나 밀접하게 결합되어 있거나 더 심하게 생성 된 경우 ( 기침 VS 테스트) 테스트를 유지하면 합창이 빠르게 이루어질 수 있습니다. 그리고 충분한 테스트로 인해 생성 된 인식 된 값보다 더 많은 작업이 시작된 후에는 스케줄이 압축 될 때 테스트가 먼저 삭제됩니다 (예 : 시간이 많이 소요됨)

모든 것을 다룰 수 있도록 테스트 작성 (100 % 코드 적용)

이상적으로, 방법론을 준수하면 기본적으로 코드가 100 % 테스트됩니다. 일반적으로 코드 적용 범위는 90 % 이상입니다. 이것은 일반적으로 템플릿 스타일 아키텍처가 있고베이스가 테스트되고 코너를 자르고 템플릿 사용자 정의를 테스트하지 않을 때 발생합니다. 또한, 이전에 경험하지 못했던 새로운 장벽에 직면했을 때이를 테스트 할 때 학습 곡선이 있음을 알게되었습니다. 나는 오래된 skool 방식으로 몇 줄의 코드를 작성하는 것을 인정하지만 실제로는 100 %를 갖고 싶습니다. (나는 학교에서 큰 성과를 거두었다고 생각한다).

그러나 TDD의 장점은 응용 프로그램을 다루는 좋은 테스트 세트를 얻을 수 있지만 한 번의 변경으로 인해 깨지기 쉽지 않은 간단한 아이디어에 대한 단점을 훨씬 능가한다고 말할 수 있습니다. 1 일과 마찬가지로 프로젝트의 300 일째에 새로운 기능을 계속 추가 할 수 있어야합니다. 이는 TDD를 시도하는 모든 사람들이 버그를 타는 모든 코드에 마법의 총알이라고 생각하는 모든 사람들에게는 해당되지 않습니다. 작동하지 않습니다.

개인적으로 TDD를 사용하면 더 간단한 코드를 작성하고 특정 코드 솔루션이 작동하는지 여부에 대해 토론하는 데 시간이 덜 걸리며 다음 기준에 부합하지 않는 코드 줄을 변경할 염려가 없다는 것을 알았습니다. 팀.

TDD는 마스터하기 힘든 학문이며 몇 년 동안 사용해 왔으며 여전히 새로운 테스트 기술을 계속 배웁니다. 초기에는 막대한 시간을 투자하지만 장기적으로는 자동화 된 단위 테스트가없는 경우보다 지속 가능성이 훨씬 큽니다. 이제 내 상사 만 알아낼 수 있다면

답변