단위 테스트는 당신에게 무엇을 의미합니까?
https://stackoverflow.com/questions/259957
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
g'day,
나는 단위 테스트라는 용어를 매우 느슨하게 사용하는 해외 개발자 그룹과 협력하고 있습니다.
그들의 QA 문서는 단위 테스트 작성과 시스템의 단위 테스트를 수행하는 것에 대해 이야기합니다.
이것은 어떤 단위 테스트가 어떤지에 대한 나의 해석과 일치하지 않습니다.
나는 단일 클래스, 일반적으로 블랙 박스로 운동하는 데 사용되는 테스트 또는 테스트 스위트 인 단위 테스트에 익숙합니다. 테스트중인 클래스는 구현에 다른 클래스를 포함하도록 요구할 수 있지만 일반적으로 단위 테스트에 의해 행사되는 단일 클래스입니다.
그런 다음 시스템 기능 테스트, 인터 레이트 테스트, 수락 테스트 등이 있습니다.
나는 이것이 내 부분에 약간 pedantic인지 알고 싶다. 아니면 이것이 단위 테스트 및 단위 테스트를 언급 할 때 생각하는 것입니까?
편집 : Rob Wells. 블랙 박스 관점에서 그러한 테스트에 접근하는 것은 한 가지 측면 일 뿐이라는 것을 명확히해야합니다. 모의 개체를 사용하여 내부 동작을 확인할 때 상자 안에서 일어나고 싶은 일을 알고 있기 때문에 흰색 상자 관점에서 실제로 테스트하는 것입니다.
해결책
단일 방법 만 테스트하기 위해 단위 테스트를 구현하려고합니다. 그리고 테스트중인 방법에 사용 된 종속 클래스 및 메소드에 대한 "모의"클래스를 크레타로 만들기 위해 노력합니다 ... ... 해당 메소드의 코드 연습이 실제로 다른 메소드에서 코드를 호출하지 않도록합니다. 테스트는 "테스트"(해당 방법에 대한 다른 단위 테스트가 있습니다)이면 이런 식으로, 단위 테스트의 실패는 단위 테스트가 테스트하는 방법의 실패를 안정적으로 나타냅니다 ...
Mock 클래스는 종속 클래스의 인터페이스 및 동작을 "시뮬레이션"하여 테스트하는 방법이 호출 할 수 있으며 시스템 요구 사항에 따라 INA 표준, 잘 정의 된 방식으로 작동합니다. 이 접근 방식을 작동시키기 위해서는 "테스터"프로세스가 대신 테스트되는 클래스에 종속 클래스의 모의 버전을 "주입"할 수 있도록 이러한 종속 클래스 및 해당 방법으로의 호출을 잘 정의 된 인터페이스에서 작성해야합니다. 실제 생산 버전의 .... 이것은 "의존성 주입"또는 "제어의 역전"(IOC)이라고하는 일반적인 디자인 패턴과 비슷합니다.
시장에는 이러한 종류의 패턴을 구현하는 데 도움이되는 여러 타사 도구가 있습니다. 내가 들었던 것은 "Rhino-mock"또는 그와 비슷한 것입니다 ...
편집 : Rob Wells. @Charles. 감사합니다. 나는 Mock Objects를 사용하여 테스트중인 클래스를 제외한 다른 클래스를 사용하여 완전히 교체하는 것을 잊어 버렸습니다.
Mock Objects를 언급 한 후에 내가 기억했던 다른 몇 가지 사항은 다음과 같습니다.
- 포함 된 클래스에서 반환되는 오류를 시뮬레이션하는 데 사용할 수 있습니다.
- 테스트중인 클래스에서 예외 처리를 확인하기 위해 구체적인 예외를 제기하는 데 사용할 수 있습니다.
- 설치 비용이 높은 품목을 시뮬레이션하는 데 사용할 수 있습니다.
- 그것들은 들어오는 요청의 내용을 확인하는 데 사용할 수 있습니다.
자세한 내용은 Martin Fowler의 논문을 살펴보십시오.모의는 스터브가 아닙니다"그리고 실용적인 프로그래머의 기사"모의 개체"
다른 팁
단위 테스트는 일반적으로 개발자가 고립 된 코드 섹션을 테스트하는 데 사용됩니다. 국경 사례, 오류 사례 및 정상 사례를 다룹니다. 그것들은 제한된 코드 세그먼트의 정확성을 보여주기위한 것입니다. 모든 단위 테스트가 통과되면, 당신은 당신의 분리 된 코드 세그먼트가 그들이해야 할 일을한다는 것을 보여주었습니다.
통합 테스트를 수행 할 때는 엔드 투 엔드 사례를보고 장치 테스트를 통과 한 모든 세그먼트가 함께 작동하는지 확인합니다. 기능 테스트를 확인하여 코드가 지정된 요구 사항을 충족하는지 확인합니다. 최종 사용자는 최종 제품을 승인하는지 확인하기 위해 수락 테스트를 수행합니다.
테스트가 일관된 비즈니스 운영 만 처리하는 한 단위 테스트가 여러 클래스 또는 하위 모듈을 걸 수없는 이유는 없습니다. 개인의 급여를 계산하기 위해 다른 전략을 사용하는 BO 방법 인 "Calculate Wage"에 대해 생각해보십시오. 제 생각에는 단위 테스트입니다.
나는 많은 단위 테스트가 먼저 수행되는 기술에 대해 들었고, 그 주변에서 개발이 이루어졌습니다. 누군가는 이것이 "테스트 중심 개발" - TDD (Elie에게 감사)라고 말한다.
그러나 이것이 해외 작전이라면이 단원 테스트를하는 데 시간을 소비하기 때문에 더 많은 돈을 청구 할 수 있습니다. 그러면 조심할 것입니다. 그들이 실제로 말하는대로하고 있는지 확인하는 단위 테스트를 경험 한 누군가로부터 두 번째 의견을 얻으십시오.
내 이해를 통해 단위 테스트는 모든 개발 프로젝트에 조금 더 많은 시간을 추가 할 것이지만 물론 품질 관리를 제공 할 수 있습니다. 그럼에도 불구하고, 이것은 집안 프로젝트와 함께 원하는 품질 관리 유형입니다. 이것은 해외 회사가 당신에게 따뜻한 퍼지를 제공하기 위해 거기에서 던지는 것일 수 있습니다.
테스트에 사용하는 프로세스와이를 지원하는 데 사용되는 기술 사이에는 차이가 있습니다. 단위 테스트에 사용되는 다양한 프레임 워크는 일반적으로 매우 유연하며 소형 코드, 큰 장치 및 전체 프로세스를 테스트하는 데 사용할 수 있습니다. 이러한 유연성은 혼란을 초래할 수 있습니다.
내 권장 사항은 다양한 단위 테스트를 별개의 어셈블리 나 모듈로 분리하는 특정 방법론이나 프로세스를 채택하는 것이 좋습니다. 정확한 계약은 귀하의 코드와 회사 조직에 따라 다릅니다.
단위 테스트 프레임 워크 사용의 누적 효과는 코드 테스트의 많은 부분이 자동화된다는 것입니다. 올바르게 채택 된 개발자는 전체 Q & A 프로세스를 거치면서 코드 코드 변경을 더 잘 평가할 수 있습니다. Q & A 프로세스 자체의 경우 개발에서 벗어나는 코드의 품질이 더 높아야하므로 시간이 더욱 생산적입니다.
모든 품질 문제에 대한 해답이 아니라 사용하는 다른 품질 문제에 대한 해답이 아니라는 것을 이해하십시오.
위키 백과 단위 테스트는 OO 프로그래밍의 경우 클래스의 방법이 될 가장 적은 양의 코드를 테스트하는 것임을 제안하는 것 같습니다.
일부는 단위 테스트에서 의미하는 바에 대한보다 일반적인 용어를 가질 수 있으며, 일부는 일부 통합 테스트를 단위가 구성 요소의 혼합 인 단위 테스트라고 생각할 수 있습니다.
전통적인 견해가 있습니다 http://en.wikipedia.org/wiki/software_testing 의 일부로 http://en.wikipedia.org/wiki/software_engineering. 그러나 나는 민첩한 단위 테스트에 대한 아이디어를 좋아합니다. 테스트는 프로그래머가 충분히 빠르면 민첩한 단위 테스트입니다. 언제나 실행하십시오.
단위 테스트는 가장 작고 자신감을 갖고 자신의 길을 가질 수 있습니다. 이것이 바로 객체 지향 아키텍처에 실제로 통합하는 방식이 아니라 회귀 및 검사 편차에 대한 방패를 반복적으로 구축합니다.
이것은 거의 반복된다 "'단위'란 무엇입니까?" 의문.
"단위"는 유연하게 정의 될 수 있습니다. 문서에 "단위"의 정의가 없으면이를 명확히해야합니다.
단위를 큰 코드 어셈블리로 생각할 수도 있습니다. 가장 바람직한 정의가 아닙니다.
여러 계층의 테스트 (단위, 모듈, 패키지, 응용 프로그램)가 있다는 데 동의하지만,이 중 많은 부분이 단위 테스트 도구로 수행 할 수 있다고 생각합니다. "유닛이란 무엇입니까?" 항상 질문이 다가릅니다.
단위는 컨텍스트에 따라 다릅니다. 개별 개발자의 경우 장치는 클래스 여야합니다. 때로는 모듈이나 패키지를 의미합니다.
그러나 팀의 경우 해당 장치는 패키지 또는 완전한 응용 프로그램 일 수 있습니다.
우리가 생각하는 것은 무엇입니까? 여기서 문제는 문서에서 사용하는 용어에 대한 불행입니다. 왜 그들과 논의하지 않습니까?
10 년 전, 코드로 작성된 테스트와 같이 현재 "단위 테스트"를 사용하기 전에 동일한 지정이 수동 테스트에 적용되었습니다. 저는 매우 공식화 된 소프트웨어 개발 프로세스를 갖춘 소프트웨어 개발 회사에서 근무했습니다. 코드를 작성하기 전에 "단위 테스트"를 작성해야했습니다. 그 시대에, 단위 테스트는 텍스트 문서 (예 : Word)로 작성되었습니다. 그들은 사용자가 앱을 사용하는 데 따라야하는 정확한 단계를 설명했습니다. 예를 들어, 새 고객을 설정하기 위해 페이지에 입력 할 정확한 입력을 설명했습니다. 또는 사용자는 특정 제품을 검색하고 표시된 정보가 테스트 문서와 일치하는지 확인해야합니다. 따라서 테스트는 테스터가 따르는 대본으로 결과를 기록했습니다. 단위 테스트의 새로운 화신이 등장했을 때, 그들은 오래된 인간 테스트 또는 새로운 코드 테스트를 의미하는지 알아 내려고 혼란 스러웠습니다.
나도 해외 팀 그룹을 이끌고 있습니다. 우리는 일련의 단위 테스트를 가지고 있지만 ... 많은 의미는 아닙니다. :) 그래서 우리는 기능적과 품질에 대한 테스터에 훨씬 더 의존합니다. 단위 테스트의 상속 문제는 기능에 대한 완벽한 지식을 가지고 있으며 개발자를 신뢰한다는 것입니다. 현실 세계에서는 가정하기가 어렵습니다 ..
