단위 테스트를 위해 프로젝트가 얼마나 커야합니까? [닫은]

내 프로젝트가 단위 테스트를 수행 할 수있을만큼 분리 된 것으로 가정합니다. 그러나 단위 테스트의 가치를 높이려면 클래스와 함수 측면에서 프로젝트가 얼마나 커야합니까?

우리 모두는 실수를 저지르고 완벽하지는 않지만 작은 프로젝트의 오류를 단계별로 처리하는 적절한 프로그래머라고 생각합니다. 아니면 프로젝트 규모에 관계없이 단위 테스트가 어려운가요?

프로젝트가 이미 충분히 큽니다.

내 경험상 하나의 클래스와 하나의 함수로 단위 테스트의 필요성을 고려했습니다.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

한 거기 사람들 확실히 있기는하지만 나는 "당신이해야 단위 테스트 다"아이디어로 구입 한 적이 없다 (참조 모기의 대답은 !).

내가 아는 한 단위 테스트의 주요 이점은 다음과 같습니다.

1. 변경으로 인해 문제가 발생하지 않도록합니다.
2. 클래스에 대한 합리적인 인터페이스를 디자인하는 데 도움을줍니다 (강제로 자신의 코드에 대한 클라이언트가되므로).
3. 코드 사용 방법을 문서화합니다.

기본적으로 이러한 요소에 대한 테스트를 작성하고 유지하는 데 걸리는 시간을 측정해야합니다.

숫자 1은 일반적으로 테스트를 작성하는 데 가치가 있습니다. 내 경험상, 코드의> 95 %가 조만간 수정됩니다.

간단합니다. 프로그램을 한 번 실행 한 후 폐기하면 유닛 테스트가 필요하지 않습니다.

이것이 당신에게 과도하게 보인다면, 대안이 무엇을 의미하는지 고려하십시오. 단위 테스트가 지불하지 않는 크기보다 작은 크기가 있다면 "마법 크기에 도달 했습니까? 테스트를 작성해야합니까?" 이제 프로그래머는 미래를 예측하는 데 악명이 높으며 자신의 기술을 판단하는 데 악명이 높습니다. 지금 당신에게 명백하게 보이는 코드는 심지어 한 달을 기다려도 이해할 수 없게 될 것입니다. 당신이 절대적으로있는 프로젝트는, 긍정적으로 특정 다시 사용되지 않습니다, 당신은 단지 당신이 전에 뭔가 해결 방법을 찾아 볼 수도 있습니다 원격 기회에 주위를 유지하는 것이 됩니다 다시 요청을하고, 변경 요청을 받게됩니다.

따라서 테스트가 도움이되는지 여부를 잘못 판단 할 가능성이 높으며 테스트가 필요할 때 테스트 할 정확한 의미가 실제로 100 % 확실하지 않습니다. 사소한 일회성 프로그램을 제외한 모든 프로그램이 단위 테스트를 통해 이익을 얻는다고 믿기 때문에 다시는 실행되지 않는 테스트에 소요되는 노력 비용이 테스트되지 않았고 이해하기 어려운 코드를 확장하는 위험에 대해 무시할 수 있다고 생각합니다.

얼마 전에 저는 단위 테스트가 개발 속도를 높이는 좋은 게시물을 발견했습니다 . 질문에 대답하는 데 도움이 될 수 있습니다.

... 코드베이스에 실질적인 단위 테스트가 제공된다면 어떻게 될까요? "모든 테스트에 성공하면 코드가 여전히 수행해야하는 작업을 보장합니다" 라고 말하고 테스트에 실패하면 일부 동작이 중단 된 위치를 정확하게 보여줍니다. 이것은 훌륭합니다. 코드가 여전히 수행해야 할 작업을 수행하면 방황하지 않고 원하는 것을 추가하도록 코드를 변경할 수 있습니다. 테스트를 실행하면 믿음이 있습니다. 이것은 소프트웨어 엔지니어가되기에 좋은 세상입니다. 나는 더 빨리 나아갈 수 있음을 알았습니다 ...

나는“믿음”이 있습니다.

이것이 아마도 단위 테스트가 엔터프라이즈 컨텍스트에서 개발 속도를 높이는 가장 중요한 이유 일 것입니다.

모든 테스트를 통과해도 모든 것이 여전히 작동한다고 믿을 수 있습니다. 테스트에 실패하면 문제가 발생한 위치를 정확하게 지적합니다 ...

... 높은 단위 테스트 범위 와 우수한 단위 테스트 를 가져야합니다 . 이러한 조건을 준수하면 새로운 기능을 추가하려는 노력이 응용 프로그램의 크기와 거의 독립적이며 장기적으로 개발 속도가 빨라지 는 상황에 처하게 됩니다 .

Michael Feathers는 그의 책 중 하나에서 코드 변경 작업을하는 두 가지 방법을 소개했습니다.

• 편집하고기도하세요
• 덮고 수정하십시오.

코드베이스가 얼마나 큰지는 중요하지 않습니다.

Kent Beck 에 따르면 Stack Overflow 질문에 대한 답변에서 단위 테스트는 얼마나 깊습니까? , 잘못되기 쉬운 코드를 테스트해야합니다.

일반적으로 생성자에서 잘못된 변수를 설정하는 것과 같은 실수를하지 않으면 테스트하지 않습니다.

시간을 절약하고 개선하기 위해 단위 테스트가 구현됩니다.

• 버그 추적
• 코드 리팩토링 및 / 또는 재 작성
• 통합 테스트
• 회귀 테스트 등

프로그램의 비교적 복잡한 부분에 대한 단위 테스트를 작성해야합니다.

지금 단위 테스트를 작성해도 나중에 시간을 절약 할 수 없다면이를 건너 뛸 수 있습니다. 그러나 당신은 결코 알지 못합니다. 개인적으로 단위 테스트를 작성하지 않고 수동으로 모든 테스트를 수행하는 것이 더 저렴한 (시간, 돈 및 신경의 의미) 경우를 생각할 수 없습니다.

"이것을 단위 테스트해야합니까?"는 일반적으로 다음과 같은 질문에 대답하여 대답 할 수 있습니다.

물론, 그것보다 훨씬 더 복잡하지만 시작하기에 좋은 방법입니다. 결국 다른 함수에서 사용되어 코드가 이미 테스트되고 있는지 또는 다른 함수에서 시간을 더 잘 소비하는지 등을 계량합니다.

테스트하지 않고 코드를 작성하지 않는 한 항상 테스트 비용이 발생합니다.

단위 테스트와 그렇지 않은 것의 차이점은 테스트 작성 비용과 테스트 비용과 직접 테스트 비용의 차이입니다.

단위 테스트 작성 비용이 2 분이고 단위 테스트 실행 비용이 실제로 0이지만 코드를 수동으로 테스트하는 비용이 1 분인 경우 테스트를 두 번 실행해도 중단됩니다.

몇 년 동안 나는 코드에 대한 단위 테스트를 작성하기에 충분한 시간이 없다는 오해를 받고 있었다. 테스트를했을 때, 그들은 부풀어 오르고 무거운 것들이 필요하다는 것을 알았을 때 단위 테스트를 작성해야한다고 생각하게 만들었 습니다 .

최근에 저는 테스트 주도 개발 을 사용하도록 권장 받았으며 완전한 계시라고 생각했습니다. 나는 이제 단위 테스트를 쓰지 않을 시간이 없다고 확신한다 .

내 경험상 테스트를 염두에두고 개발하면 더 깨끗한 인터페이스, 더 집중된 클래스 및 모듈 및 일반적으로 더 많은 테스트 가능한 SOLID 코드가 생깁니다.

단위 테스트가없는 레거시 코드로 작업하고 수동으로 무언가를 테스트해야 할 때마다 "이 코드에 이미 단위 테스트가있는 경우 훨씬 빠를 것"이라고 계속 생각합니다. 높은 커플 링으로 코드에 단위 테스트 기능을 추가하려고 할 때마다 "이것이 분리 된 방식으로 작성된 경우 훨씬 쉬울 것"이라고 계속 생각합니다.

TL; DR 버전 :

테스트 작성 비용과 테스트 실행 비용이 필요한 횟수만큼 수동 테스트 비용보다 적을 경우 테스트를 작성하십시오.

TDD를 사용하면 테스트 작성 비용이 나아질수록 테스트 작성 비용이 낮아질 가능성이 있으며 코드가 절대적으로 사소하지 않으면 테스트를 더 자주 실행하게 될 수 있습니다.

회귀가 발생하거나 편집 한 내용이 눈에 띄지 않게되는 것을 두려워하는 즉시 테스트 하십시오.

두려워하는 킨들, 적절한 크기로 자라게하십시오. 테스트할수록 빠를수록 좋습니다.

참고 : 프로젝트에서의 역할에 따라 단위 테스트 만 작성하려는 테스트가 아닐 수도 있습니다.

과거의 잘못된 주류 테스트 관행으로 인해 모든 사람들은 단위 테스트에 합당하게 집착 합니다. 그러나 이전에 테스트 한 적이 없다면 일반적 으로 테스트에 중점을 두어야합니다 . 단위 테스트만으로는 세계의 문제를 해결할 수 없습니다.

프로젝트의 크기가 아니라 테스트를 사용해야하는지 여부를 결정하는 프로젝트 유형이라고 생각합니다.

개념 증명 또는 코딩에서 배우는 것이 목표 인 다른 프로젝트에서 작업하는 경우 테스트가 필요하지 않습니다. 프로젝트가 사용되어야하고 생산으로 보내질 예정이라면 테스트를 거쳐야합니다.

Robert C. Martin의 "Clean Code"의 인용문 : "쓰기가 쉽지 않다면 테스트하기가 쉽지 않습니다."짧고 사소한 프로그램에 대한 테스트를 건너 뛸 이유가 없습니다.

그것은 실제로 크기의 문제가 아닙니다. 그것은 당신이하는 일 (그리고 오래된 것)입니다. 기술이 어떻게 작동하는지 배우고 문제를 버릴 계획이라면 (우리는 이것을 스크럼에서 스파이크라고 부릅니다), 많은 테스트를 수행하지 않고 코드를 작성합니다. 더 개발하려고 계획하고 있다면 (여전히 신경 쓰지 않아도) 코드에 대한 테스트를 작성해야합니다. TDD는 테스트 기술이되기 전에도 설계 기술입니다. 실행의 세부 사항에 묶이기 전에 코드가 무엇을 원하는지 명확하게 파악하려고합니다. 나는 또한 하지 않을 것이다대량의 레거시 코드에 대해 광범위한 단위 테스트를 작성하는 것이 좋습니다. 복잡한 부품 (사이클로 매틱 복잡성 / 스파게티 코드 느낌이 높음)과 자주 실패하는 부품 (주로 동일 함)을 식별하십시오. 다른 사람들이 제안했듯이, 나는 TDD에 관한 Kent Beck의 책을 읽고 Michael Feather의 책을 확실히 읽을 것입니다. 그들이 다루지 않은 것은 코드에 대한 단위 테스트를 작성 하는 정치적 측면입니다. 많은 개발자들이 코드를 테스트 가능하게 만들기 위해 코드를 변경하는 것을 싫어하고 많은 개발자들은 코드를 전혀 테스트 할 필요가 없다고 생각합니다. 직업으로서 우리가해야 할 일입니다. 다른 모든 공학 분야는 해당 작업이 사양을 충족했음을 증명해야합니다. 우리도 똑같이해야합니다.

클래스 또는 기능의 한계에서 프로젝트를 바인딩 한 다음 이것이 유닛 테스트에 적합한 지 판단하는 것은 잘못되었을 수 있습니다. 응용 프로그램을 단위 테스트하면 많은 이점이 있지만 응용 프로그램을 유지 관리하거나 분산 환경에서 작업해야 할 때 진정한 아름다움이 시작됩니다. 선택이 여기에 온다. 코드를 조금만 변경해도 재해가 발생할 수 있습니다.
나는 'Unit Testing'을 제안 할뿐만 아니라 코드 범위를 확인하여 최대 코드가 단위 테스트로 적용되도록 권장합니다. 코드 적용 범위의 임계 값은 95 % 이상 이어야하며 목표는 약 100 % 여야합니다 . 코드 범위를 추적하고 보고서를 생성하는 도구를 사용할 수 있습니다.
범위 데이터를 제공하는 Visual Studio-http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
또한 NCover 또는 dotCover를 사용할 수 있습니다.