저는 단위 테스트의 이점에 대해 조사해 보았습니다. 코드 정확성과 올바른 이점을 확인하면 제대로 연결하면 느슨하게 결합 된 코드가 자연스럽게 생성됩니다. 즉 단위는 한 가지 방법만큼 작습니다. 더 크지는 않습니다. 이것들은 큰 것 같습니다 2. 좋은 단위 테스트가 링 - 울타리 코드가되고 다른 개발자 코드 변경에서 그 기능을 보호하는지 알고 싶습니다 (실패한 단위 테스트가 실패한 빌드라고 가정). 또한 간과 한 다른 이점이 있습니까?단위 테스트는 다른 개발자의 실수로부터 코드를 보호합니까?
알맞은 단위 테스트 범위를 갖는 다른 이점 (간과 된) 중 하나는 개발자가 자신의 발끝을 큰 솔루션/오래된 레거시 코드에 담그는 것을 실제로 촉진 할 수 있다는 사실입니다. 리팩터링이 잘못되었을 때의 피드백
예, 대부분의 시간 동안 단위 테스트는 실제로 다른 개발자의 실수를 방지합니다. 그러나 이것은 항상 사실이 아닙니다. 테스트 포인트는보다 실용적인 솔루션을위한 더 나은 선택입니다.
다른 개발자가 테스트를 삭제하지 않을지 여부에 달려 있습니다.
하지만 코드를 올바르게 모듈화하고 테스트를 명확히하면 일반적으로 사람들은 테스트를 중단하면 코드를 변경하는 것에 대해 두 번 생각할 것입니다.
변경을해야 할 충분한 이유가없는 한 - 그러면 새 기능을 설명하기 위해 그에 따라 테스트를 변경해야합니다.
단위 테스트는 다른 개발자의 실수로 코드를 보호합니까?
정확하게는 아닙니다.
단위 테스트는 특정 코드 조각 ("단위")을 격리하고 양수 및 음수 방식으로 호출하여 예상 결과에 대해 매번 출력을 테스트합니다. 이렇게하면 유닛이 견고하며 해당 유닛의 컨텍스트 내에서 예상되는 요구 사항 인 을 충족시킵니다..
다른 개발자가 코드에 값을 전달하거나 반환 값에 대해 잘못 행동하기 전에 실수를 저지르는 것은 아닙니다. 코드에 전달 된 값은 유효 할 수 있지만 여전히 잘못되었습니다. 예를 들어, 코드는 0에서 100 사이의 양의 정수를 예상 할 수 있지만 코드에서 50을 전달하는 특정 호출자가 잘못되었다는 것을 알지 못합니다. 즉, 코드는 수신 한 내용에 따라 행동 할 수 있습니다. . 이 경우 해당 호출 코드의 유닛 테스트가 문제를 해결할 수 있지만 코드의 유닛 테스트는 실패합니다.
난 그냥 좋은 단위 테스트는 코드 울타리 링과 다른 개발자의 코드에서 그 기능을 보호 할 수 있는지 알고 싶은
단위 테스트는하지 링 울타리 아무것도 변경됩니다. 잘 작성된 테스트를 가정하면 코드가 변경되어 더 이상 원래 의도와 일치하지 않는다고 알려줍니다. 그들은 호출자가 런타임에 잘못된 값을 전달하는 경우 알려주지 않지만 잘못된 값이 전달되면 코드가 올바르게 작동하는지 확인할 수 있습니다.
내 경험에 따르면 단위 테스트는 다음과 같습니다. 코드를 작성하는 사람이 좋아. 그 사람이 가난한 코더이거나 요구 사항을 제대로 이해하지 못하면 테스트가 무의미 할 수 있습니다. 과거에 정말 끔찍한 단위 테스트를 보았습니다. 결과적으로 테스트 접근 방식의 한 부분 일 것을 항상 권고합니다. 이들을 독점적으로 의존해서는 안되며, 단지 훈련 된 접근 방식의 일부일뿐입니다.
적절한 캡슐화는 다른 개발자 실수를 예방하는 데 도움이됩니다. 계획, 모듈 또는 논리의 계획되지 않은 사용을 "사용하도록 허용"하는 것으로 제한함으로써 다른 개발자의 오류를 제한 할 수 있습니다. 단위 테스트는 그 어느 것도하지 않습니다. 반대로, 단위 테스트는 종종 기능적으로 필요한 것 이상으로 코드 기반을 열 것을 요구합니다. 단원 테스트는 모듈과 메서드가 예상대로 변경되지 않도록 유지해야합니다. –