우리 프로젝트는 현재 유지 보수 중입니다. 우리는이 프로젝트에 대한 단위 테스트를 한 적이 없습니다. 우리는 전체 응용 프로그램에 대한 단위 테스트를 작성하는 대신 델타 단위 테스트를 작성할 계획이었습니다. 선호되는 접근 방법은 무엇입니까? 유지 보수 단계에서 단위 테스트를 추가하는 것이 실제로 가치를 더합니까 ??? 우리는 아직 .net 1.1을 사용 중이며 향후에 .net 4.0으로 업그레이드 할 예정입니다.유지 보수 단계에서 단위 테스트
누군가가 ROI를 사업에 판매했는지 궁금합니다.
선호하는 접근 방식은 기존 코드를 모두 으로 덮어 쓰고 델타 버전을 사용하는 것이지만 예산은 충분하지 않을 수 있습니다. 변경 사항에 대한 단위 테스트는 아무 것도없는 것보다 낫습니다.
이미 적절한 통합/확인/수락 테스트를 거친 경우라면 충분할 것입니다.
이상적으로 미래의 델타뿐만 아니라 전체 프로젝트를 다루는 단위 테스트가 있어야합니다. 이는 주요 인프라 업그레이드를 계획 할 때 특히 중요합니다. 이는 기본적으로 전체 프로젝트가 "델타"라는 것을 의미하기 때문입니다.
이 작업을 실제로 수행 할만한 가치가 있는지 여부는이 프로젝트를 얼마나 실제로 지원할 것인지에 달려 있습니다.
모두는 얼마나 자주 그리고 왜 코드가 왜곡되는지에 따라 다릅니다. 그러나 어떤 경우 든 단위 테스트 및 포괄적 인 단위 테스트 스위트는 장기 투자와 더 비슷합니다.
대부분의 변경 사항은 현장/고객 문제로 인해 유지 관리 단계의 UnitTest (유지) 코드의 ROI가 문제를 해결하는 시간 단축으로 인한 것이므로 도입 된 (또는 노출 된) 버그 수를 줄이고, 델타와 협력하고 문제의 근본 원인을 밝히는 데 걸리는 시간을 줄입니다.
코드 변경이 작은 기능 (개선 및/또는 고객 요청)으로 인해 발생하는 경우 ROI가 더 짧은 배달 시간 (더 우수한 품질의 코드, 더 높은 신뢰도, TDD 사용 등)으로 이루어져야합니다.
일반적으로 단위 테스트를 통해 개발자는 코드 기반에 대한 개발자의 신뢰를 높이고 변경 사항에 대해 일종의 안전망을 제공해야합니다.
텍스트에서 'ROI'라는 약어를 삭제하고 더 이해하기 쉬운 것으로 바꿀 수 있습니까? ROI 검색을했는데이 질문에 가까운 유일한 정의는 ROI입니다. 그러나 ROI를 실현할 수 없으므로 나는 당혹 스럽다. – Unapiedra