응용 프로그램을 상속 할 때 이미 작동하는 코드에 대한 단위 테스트를 작성하는 데 가치가 있습니까?

분명히 일부 오래된 응용 프로그램은 처음 작성된 방식으로 인해 단위 테스트가 불가능하거나 매우 어렵습니다.

그러나 단위 테스트가 가능한 일부 도우미 메서드와 같은 장소에서 단위 테스트를 작성해야합니까?

내 말은, 개처럼 쓸 수는 있지만 논리를 복잡하게 깨뜨릴 수 있지만 시간의 시험은 그것이 제대로 작동한다는 것을 증명했습니다. 단위 팩터를 리팩토링한다고 할 때 단위 테스트를 귀찮게해야합니까, 아니면 시간이있을 때마다 단위 테스트를 작성해야합니까?

이 작업에 가치가 있습니까?

또한 방법 정의가 모호 할 수 있다는 점을 고려하고, 주어진 조건에서 일부 방법이 실제로 어떻게해야하는지 조사해야 할 수도 있습니다.

응용 프로그램에 대해 가능한 한 많은 테스트를 작성해야한다고 생각합니다. 코드베이스를 배우고 최종 리팩토링 또는 새로운 개발을 준비하는 데 도움이됩니다.

이 시나리오에서 작성할 수있는 몇 가지 종류의 테스트가 있으며 각 테스트에는 고유 한 장점이 있습니다. 이 테스트를 작성하면 다루는 응용 프로그램에 대해 많은 것을 배울 수 있습니다.

우선, 정확성 테스트를 작성하기 전에 현재 행동을 포착하는 테스트를 작성하십시오 . 코너 케이스 또는 프로그램을 실행하여 철저히 테스트하지 않은 코드 부분의 버그를 발견하는 것이 안전합니다. 코드의 기능에 대해 걱정하지 말고 코드를 수행하십시오. 진행하면서 코드를 읽거나 출력 내용을 파악하는 데 많은 시간을 소비하지 않아도됩니다. 테스트를 실행하고 해당 출력을 어설 션으로 캡처하십시오.

이를 통해 코드의 작동 방식과 주요 문제점 또는 약점을 파악할 수 있습니다. 버그를 발견하면 능력이있는 사람들에게 접근하여 문제를 해결할 가치가 있는지 여부를 결정하고 결정을 내릴 수 있습니다.

다음으로, 단위 테스트가 쉽지는 않지만 가능한 한 워크 플로를 테스트하는 것이 중요한 코드 부분을 다루는 몇 가지 더 큰 (범위 내) 테스트를 작성할 수 있습니다. 이러한 워크 플로우 테스트 또는 통합 테스트 는보고자하는 방식에 따라 워크 플로우를 리팩토링 할 수있는 좋은 기반을 제공하여 기존 워크 플로우에 영향을 줄 수있는 새로운 기능을 추가해야하는 경우이를보다 효과적으로 테스트하고 보호 할 수 있습니다.

시간이 지남에 따라 응용 프로그램을 상속받는 다음 사람을 돕기 위해 일련의 테스트를 작성하게됩니다.

단위 테스트는 단순한 테스트가 아니라 사양으로 간주합니다. 특정한 경우에 새 사양에 맞게 변경하기 전에 단위 테스트를 실시하면 실제 가치가 언급됩니다. 상속 된 코드를 변경하려는 경우 가장 좋은 방법은 기능에 대한 단위 테스트를 수행하는 것입니다.이 기능은 안전망을 가져올뿐만 아니라 특정 단위가하는 일을 더 명확하게하는 데 도움이됩니다. 그것은 또한 당신이 언급 한대로 이해하기에 좋은 연구를하도록 강요 할 수도 있습니다. 그래서 모듈을 변경하기 전에 모듈의 단위 테스트를 수행해야합니다.

 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

아니요 . 내 경험상 프로덕션 코드가 작성된 후 단위 테스트를 작성 하는 데 나쁜 비용 / 이점 관계 가 있습니다. 리팩토링없이 코드를 분리 하여 테스트하는 방법을 찾기가 어렵거나 어렵 기 때문입니다 . 테스트 주도 개발의 장점 중 하나는 느슨하게 결합 된 코드를 얻는다는 것입니다. 나중에 테스트를 작성하면 코드가 단단히 결합 될 가능성이 높습니다.

예 , 변경하려는 기능에 대한 응용 프로그램의 통합 테스트 를 작성할 수 있습니다. 이 방법으로 회귀 테스트 를 통해 변경 사항이 적용되는지 확인할 수 있습니다.

품질과 개발자의 관점에서 그렇습니다 . 테스트를받는 것이 좋습니다.

실제 비즈니스 가치를 얻기 위해 시간 / 돈이 필요한 고객을 판매하기가 매우 어렵 기 때문에 비즈니스 관점에서 NO. 그러나 비즈니스 변경으로 인해 상황이 악화되지 않을 것이라는 모호한 약속.

가능 하면 "이미 작동하는"기존 코드에 대한 테스트를 작성해야 할 더 많은 이유가 있습니다. 테스트가 없다면 코드가 냄새가 나고 광범위한 리팩토링을 사용하여 개선 할 가능성이 있습니다. 테스트 스위트는 리팩토링하는 데 도움이됩니다. 원본 코드가 제대로 작동 하지 않을 수도 있습니다 . 판매 보고서를 생성하는 방법에 대한 테스트를 작성하면 제대로 계산되지 않았으므로 판매가 실제보다 수천 달러 더 많았으며 5 년 동안 코드가 생산되었다는 사실을 아무도 알지 못했습니다. (행운 적으로 그것은 실제 재정적 목표가 아니라 판매 보고서 추정치였습니다).

물론이 조언은 실제로 테스트를 작성할 수있는 경우에만 적용됩니다 . 내 경험상 테스트가없는 코드베이스는 테스트를 개선하기가 거의 불가능합니다. 코드 모듈의 절반을 다시 작성하여 테스트를 지원하기에 충분할 정도로 추상화해야하기 때문에 그렇게 할 수 없기 때문입니다.

단위 테스트는 정확성을 확인하지 않고 시스템의 실제 동작을 특성화해야하므로 절대적으로 yes 입니다. 특히 레거시 프로젝트의 경우 많은 요구 사항이 실제 동작으로 암시 적으로 인코딩됩니다.

이 특성화는 기본 기능의 역할을합니다. 비즈니스 관점에서 동작이 올바르지 않더라도 동작이 더 멀리 저하되지 않습니다. 레거시 프로젝트에서 견인력을 얻는 것은 어려울 수 있으며, 이는 상황을 악화시키지 않고 앞으로 나아갈 수있는 기준을 제공합니다.

따라서 가능한 모든 단위 테스트를 작성하십시오. 테스트 할 수없는 코드의 경우, 테스트 할 코드를 테스트하지 않을 코드와 분리 할 수있는 위치에 코드에 "이음새"를 도입하여 종속성을 분리하도록 코드를 리팩터링하십시오.

특성화 테스트 및 이음새로서의 단위 테스트의 아이디어는 내가 강력하게 권장하는 책인 Michael Feathers의 레거시 코드 를 이용한 효과적인 작업의 요점입니다 .

문서화되지 않은 이음새가 많이 작성되지 않았지만 시스템에서 레거시 코드가 작동하기 때문에이 문제에 대해 깊이 생각했습니다.

당신은 좋은 지적을합니다 :

단위 팩터를 리팩토링한다고 할 때 단위 테스트를 귀찮게해야합니까, 아니면 시간이있을 때마다 단위 테스트를 작성해야합니까?

요구 사항이 변경되면 단위 테스트를 작성하는 것이 가장 가치 있다고 생각합니다. 그렇지 않으면 모든 조건을 알지 못하기 때문에 적절한 테스트를 작성할 수 없기 때문에 특히 귀찮게하지 않을 것입니다.

내가 시간이있을 때마다?

우선 순위를 정할 때가 있습니다. 맞습니까? :)

프로덕션 응용 프로그램에서 이전에 사용되지 않은 해당 코드베이스의 측면을 활용하려고합니까? 이러한 시나리오에 대한 단위 테스트를 먼저 작성하십시오. 여기에서 작업의 우선 순위를 정할 수 있어야하며, 단위 테스트 기술 (Art of Unit Testing) 에 대한 조언이 있다고 생각합니다 (특히 레거시 코드베이스 테스트 방법).

응용 프로그램이 시작되어 실행 중이기 때문에 모든 것이 제대로 작동한다고 가정하지 마십시오. 일반적으로 "시간 테스트"는 a) 아직 나머지 결함을 발견하지 못했거나 b) 발견 한 사람들을 보여줍니다. 그들은 그들을보고하지 않았습니다. (또는 둘 다 가능합니다.) 그리고 아마도 현재 작동하고있는 코드조차도 다음에 변경해야 할 때 작동하지 않을 수 있습니다.

단위 테스트를 통해 특정 기능이 그대로 유지되는지 확실하게 확인할 수 있으며 합리적인 수량의 사례에 대해이를 입증 할 수 있습니다. 그것은 하나의 버그 수정이라도 "이것을 찌르고 테스트하는 것"보다 훨씬 더 가치가 있습니다. 주변을 둘러 보는 것은 통합 또는 시스템 테스트와 비슷하므로 수동으로 앱을 테스트하면 단위 테스트만으로 수행 할 수있는 것이 아니라 비효율적 인 방식으로 시간을 소비합니다. 이러한 테스트를 자동화하는 방법도 있습니다. 수동으로하는 것보다 낫습니다.)

수정 또는 리팩토링 여부에 관계없이 코드를 변경할 때 테스트를 작성해야합니다. 다음 번에 결함을 수정해야 할 때를 제외하고 다음에 시간을 절약하는 것 외에 다른 이유가 없다면 다음과 같이 테스트를 작성하는 것이 좋습니다. 소프트웨어에 항상 결함이없는 척하는 사람들의 기대와 그 시간의 균형을 유지해야하므로 향후 유지 관리에 소요되는 시간이 "낭비"됩니다. (그렇다고해서 현재 일정을 무시해야한다는 의미는 아닙니다.) 어떤 시점에서, 이렇게하면 레거시 응용 프로그램에서 테스트의 가치를 시연 할 수 있고 충분한 비용을 지출 할 수 있습니다. 미래의 앱에 대한 그 시간은 결국 생산적인 개발에 소비 할 시간을 확보해야합니다.

내 라라 랜드에서 나는 그렇다고 말할뿐만 아니라 해킹하고 리팩토링하고 테스트를 계속하지만 다른 중요한 프로젝트에 뒤지지 않도록하십시오. 작업중인 프로그래머로서 직업이 위험에 처했거나 관리자가 귀하에게 소유권을 가져 오라고 요청한 경우, 그렇습니다. 팀이나 회사가 어려움을 겪을 경우 회사와 재난을 방지하기 위해 테스트를 수행해야한다는 사실을 관리자에게 알리십시오. 그가 걱정하지 않는다고 말하면, 당신은 갈망에서 벗어날 것입니다.

행운을 빕니다!