저는 소규모 회사에서 솔로 개발자로 일하고 있습니다. 저는 회사에서 유일하게 개발자입니다. 정기적으로 작성하고 유지 관리하는 여러 개의 (상대적으로) 대규모 프로젝트가 있으며 그 중 어느 것도 프로젝트를 지원할 테스트가 없습니다. 새로운 프로젝트를 시작할 때 종종 TDD 방식을 시도해야하는지 궁금합니다. 좋은 생각처럼 들리지만 솔직히 관련된 추가 작업을 정당화 할 수는 없습니다.
나는 내 디자인에서 앞으로 생각하기 위해 열심히 노력합니다. 확실히 언젠가 다른 개발자가 내 코드를 유지 관리하거나 최소한 문제를 해결해야한다는 것을 알고 있습니다. 가능한 한 단순하게 유지하고 파악하기 어려운 사항에 대해서는 언급하고 문서화합니다. 사실이 프로젝트는 규모가 크거나 복잡하지 않기 때문에 괜찮은 개발자가 이해하기 힘들다.
테스트에서 본 많은 예제는 코드의 모든 측면을 다루면서 축소되어 있습니다. 나는 유일한 개발자이고 전체 프로젝트의 코드에 매우 가깝기 때문에 쓰기 후 수동 테스트 패턴을 따르는 것이 훨씬 효율적입니다. 또한 테스트를 유지 관리하면 프로젝트에 상당한 양의 드래그가 추가 될 정도로 요구 사항과 기능이 자주 변경되는 것을 발견했습니다. 그렇지 않으면 비즈니스 요구를 해결하는 데 소비 할 수있는 시간입니다.
그래서 매번 같은 결론을 내립니다. 투자 수익률이 너무 낮습니다.
고용 일 기준으로 누군가가 회사에 몇 년간 있었는지 계산하는 것과 같이 알고리즘을 올바르게 작성했는지 확인하기 위해 때때로 몇 가지 테스트를 설정했습니다. 그러나 코드 범위 관점에서 코드의 약 1 %를 다루었습니다.
내 상황에서 여전히 단위 테스트를 정기적으로 수행하는 방법을 찾습니까, 아니면 그 오버 헤드를 피하는 것이 정당합니까?
업데이트 : 내 상황에 대해 몇 가지 제외했습니다. 프로젝트는 모두 웹 응용 프로그램입니다. 모든 코드를 다루려면 자동화 된 UI 테스트를 사용해야하는데, 이는 여전히 수동 테스트보다 큰 이점이없는 영역입니다.