나는 충동적인 코더이며 프로그래밍에있어 인내심을 배우기 시작했습니다. 내가 잘못 처리하는 부분 중 하나는 기존 코드를 수정할 때입니다. 내가 모든 세부 사항을 내 앞에 놓지 않았다면 필연적으로 회귀로 이어지는 특정 길을 놓치게됩니다. 나는 "Implementation Patterns"를 읽을 때까지 코딩을 잘했지만 코드의 유지 보수를 과소 평가했다.회귀 관리
내 질문은 기존 코드를 유지하는 경우 어떻게 모든 기반을 커버하고 움푹 들어간 곳을 남기지 않는지 확인하는 것입니다. 코드가 손상 될 수있는 위치를 모를 때 사용하는 전략은 무엇입니까?
단위 테스트. 변경 사항을 적용 할 때 테스트를 다시 실행하고 아무 것도 손상시키지 않았는지 확인하려면 테스트 커버리지가 필요합니다. 당신이 지속적인 통합이있는 경우
, 당신은 체크인시 /가. 난 당신의 변화가 작은 있는지 확인 일찍/자주 에을 확인하는 것처럼 다음이 표시됩니다, 당신은 쉽게의 원인을 추적 할 수 버그.
두통은 단위 테스트를 이미 기존 프레임 워크에 추가하고 있습니다. dependency injection 및 mocking을 허용하기 위해 기존 라이브러리의 일부를 리엔지니어링해야 할 것입니다. 불행히도 이러한 변경 작업을 수행하는 것은 위험이 따르는 것이 아니라 가능한 한 조기에 테스트를 작성하고 코드를 테스트 친화적으로 처리하는 것이 중요합니다.
몇 가지 엣지 케이스를 파악할 수 있다면 몇 가지 단위 테스트를 작성할 수 있습니다. 그런 다음 수정 한 후에도 테스트가 계속 통과하는지 확인할 수 있습니다.
어리석은 증거는 아니지만 아무것도없는 것보다 낫습니다!
사실, TDD를 사용하여 코드를 개발 한 경우 단위 테스트에서 다루지 않는 코드가 없습니다. 실패한 단위 테스트를 충족하는 데 필요하지 않으면 코드가 작성되지 않았습니다. –
John - 변경 요청으로 인해 변경 될 수 있으며 버그로 인해 필요하지 않을 수 있습니다. 막판 변경 요청으로 인해 MS Datagridview에 대한 경험이 컸습니다. –
단위 테스트. 간단히 요약하면 다음과 같습니다. 단위 테스트 작성의 이점 중 하나는 리팩토링/나중의 코드 변경 사항을 더욱 안전하게 만들 수 있고 변경 사항이 아무 것도 위반하지 않았다는 확신을 줄 수 있다는 것입니다.
이 코드는 소스 코드에서 주기적으로 최신 코드를 뽑아 내고 모든 유닛 테스트가 실행되는 연속 통합 환경과 연계되어 있습니다. 코드 변경으로 인해 코드가 변경되면 자동으로 매우 빠른 피드백을받을 수 있습니다. 짓다.
고마워, 브라이언. UT를 개선 할 필요가 있다고 생각합니다. –