TDD 규칙에 따르면 생산 코드 전에 단위 테스트가 작성되지만 콘크리트 (모의가 아닌) 유선 객체 사이의 상호 작용을 수행하는 통합 테스트는 어떻습니까?
“배선”을 테스트하기 위해 단위 테스트 전에 또는 생산 코드 후에 작성해야합니까?
수락 또는 기능 테스트가 아니라 하위 수준 통합 테스트에 대해 이야기하고 있습니다.
답변
다른 BDD 리소스 중에서 Rspec Book 은 다음과 같은주기를 제안합니다.
본질적으로 프로세스는 다음과 같습니다.
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
면책 조항 : 이것이 최고의 코드와 제품으로 이어진다는 것은 의심의 여지가 없지만 시간이 오래 걸릴 수 있습니다. 통합 테스트는 항상 통과해야한다고 말하면 데이터 및 결정론에 어려움이 있습니다. 모든 상황에 적합하지는 않습니다. 때때로 당신은 단지 문 밖으로 물건을 가져와야합니다.
이상적인 프로세스를 염두에 두는 것이 좋습니다. 그것은 당신에게 타협점을줍니다.
답변
실제 프로젝트는 단위 테스트를 작성할 수 없으며 통합은 가능하지 않으며 반대 방향조차 잘못되었다는 것을 나에게 보여주었습니다.-) 따라서 일반적으로 단위 테스트를 통합 테스트와 함께 작성합니다.
왜? 두 종류의 테스트를 어떻게 볼 수 있는지 작성하겠습니다.
-
단위 테스트 -Wikipedia 및 모든 알려진 정보 외에도 단위 테스트를 통해 설계 범위 를 좁히고 모델을 개선 할 수 있습니다. 흐름은 간단합니다. 새 프로젝트 / 새 구성 요소를 입력하기 시작하면 대부분 PoC를 만듭니다. 완료되면 항상 긴 메소드, 긴 클래스, 일관성없는 메소드 및 클래스 등이 있습니다.
단위 테스트는 위에서 설명한 모의 클래스 (다른 구성 요소에 의존하지 않음)를 사용하여 실제 단위 테스트를 수행 할 때 테스트 할 수없는 것처럼 이러한 문제를 제거하는 데 도움이됩니다. 테스트 할 수없는 코드의 기본 표시는 많은 종속성 (또는 상황)을 조롱해야하기 때문에 테스트의 큰 조롱 부분입니다.
-
통합 테스트 -정확하고 작동하는 테스트에 따르면 새 구성 요소 (또는 구성 요소)가 다른 구성 요소와 함께 또는 다른 구성 요소와 함께 작동한다는 것이 일반적입니다. 통합 테스트는 주로 소비자 측 에서 구성 요소를 사용하는 방법을 정의 하는 데 도움이된다는 것을 알았습니다 .
API가 외부에서 이해가되지 않는 경우가 종종 있기 때문에 이는 매우 중요합니다.
나중에 단위 테스트와 통합 테스트를 작성한 후에는 어떻게됩니까?
좋은 클래스, 명확한 디자인, 좋은 생성자, 짧고 일관된 메소드, IoC 준비 등을 얻었습니다. 통합 또는 GUI 팀의 개발자와 같은 일부 소비자에게 클래스 / API를 제공하면 논리적이지 않은 것처럼 API를 사용할 수 없었습니다. 이상하다. 그는 단지 혼란 스러웠다. 그래서 그의 관점에 따라 API를 수리했지만 메소드를 변경하고 때로는 API를 사용하는 방법을 강요하기 때문에 많은 테스트를 다시 작성해야했습니다.
나중에 통합 테스트와 단위 테스트를 작성하면 어떻게됩니까?
나는 정확한 흐름, 좋은 유용성을 얻었다. 내가 가진 것은 큰 클래스, 비 일관성 코드, 로깅 없음, 긴 메소드입니다. 스파게티 코드
내 조언은 무엇입니까?
나는 다음과 같은 흐름을 배웠다.
- 코드의 기본 골격 개발
- 소비자 관점에서 적합한 지 여부를 나타내는 통합 테스트를 작성하십시오. 기본 사용 사례로 충분합니다. 테스트는 분명히 작동하지 않습니다.
- 각 클래스에 대한 단위 테스트와 함께 코드를 작성하십시오.
- 나머지 / 누락 통합 테스트를 작성하십시오. 코드를 개선하는 방법은 # 3 내에 이러한 테스트를 구현하는 것이 좋습니다.
내가 만든 적이 있습니다 작은 프리젠 테이션 , 단위 / 통합 테스트에 대한을 골격 설명 슬라이드 # 21를 참조하십시오.
답변
단위 테스트 는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어 비트를 테스트하고 해당 기능을 테스트하는 데 사용됩니다. 각 장치는 응용 프로그램의 일부 또는 더 큰 구성 요소로 통합하기 전에 별도로 테스트됩니다.
그건 어디 통합 테스트가 : 와서
그들은 함께이 부분을 피팅하는 동안 이전에 테스트 단위로 구성이 새로 만든 부품을 테스트합니다. 응용 프로그램 자체를 작성하는 동안이 시점에서 테스트를 작성하는 것이 가장 좋습니다.
답변
통합 테스트는 단위 테스트와 매우 유사하다고 생각합니다. 그 점에서 코드의 하위 집합을 블랙 박스로 취급하고 있습니다. 따라서 통합 테스트는 더 큰 상자입니다.
프로덕션 코드 전에 작성하는 것을 선호합니다. 이것은 아직 연결하지 않은 부분이나 객체 상호 작용의 세부 사항을 약간 변경했다는 것을 기억하는 데 도움이됩니다.
답변
승인 테스트 외에도 응용 프로그램 경계에서 통합 테스트를 작성하여 타사 시스템이나 구성 요소와 잘 통합되는지 확인하는 경향이 있습니다.
아이디어는 써드 파티가 애플리케이션에서 요구하는 방식으로 변환하는 어댑터 오브젝트를 작성하고 실제 외부 시스템에 대해 이러한 변환기를 테스트하는 것입니다. 그 테스트 우선 또는 마지막 테스트 여부는 일반 단위 테스트보다 덜 중요하다고 생각합니다.
-
TDD가 제공하는 디자인 통찰력은 여기에서 중요하지 않습니다. 디자인은 이미 잘 알려져 있고 일반적으로 굉장히 복잡하지는 않기 때문에 한 시스템에서 다른 시스템으로 항목을 매핑하기 만하면됩니다.
-
처리하려는 모듈 / 시스템에 따라 시간이 걸리고 짧은 TDD 피드백 루프에는 적합하지 않은 많은 탐색, 구성 땜질, 샘플 데이터 준비가 필요할 수 있습니다.
그러나 조금 안전한 단계로 점차적으로 어댑터를 빌드하는 것이 더 편안하다고 느낀다면 테스트 우선으로 진행하는 것이 좋습니다.
이 방법의 예는 여기에서 찾을 수 있습니다.
http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (6 번째 단락)
http://blog.8thlight.com/eric- smith / 2011 / 10 / 27 / thats-not-yours.html
답변
그래서 첫 번째 답변을 수락하려고했지만 삭제되었습니다.
그것을 요약하면
주어진 반복에서 :
- 단위 테스트 작성
- 생산 코드 작성
- 상호 작용을 테스트하기위한 통합 테스트 작성
통합 레벨에서 테스트 가능성을 보장하기 위해 1 및 2 동안 통합 테스트를 명심하십시오.
통합 테스트는 반드시 3 단계에서 끝까지 작성되는 것은 아니며 1 단계와 2 단계 사이에 부분적으로 작성 될 수 있습니다.
답변
단위 테스트는 프로젝트 내의 개별 코드 블록을 테스트 합니다.
통합 테스트는 코드가 다른 코드와 어떻게 인터페이스하는지 테스트합니다. 즉, 코드 의 인터페이스 를 테스트합니다 .
인터페이스 뒤에서 코드를 개발할 때 단위 테스트를 작성하십시오.
인터페이스 또는 인터페이스를 구현하는 코드를 개발할 때 통합 테스트를 작성하십시오.
이는 대부분의 작업이 인터페이스 뒤에 있기 때문에 때때로 프로젝트에서 매우 늦게 통합 테스트를 작성한다는 것을 의미합니다. 예를 들어, 컴파일러, 여러 계층의 로직을 구현하는 특정 웹 서비스 또는 .. 내부 논리.
그러나 REST 서비스 세트를 구현하거나 데이터 모델을 리팩토링하고 XA 트랜잭션에 대한 지원을 추가하는 경우 대부분의 작업이 인터페이스 중심인지 여부에 따라 대부분의 작업이 인터페이스를 중심으로하므로 거의 즉시 통합 테스트 개발을 시작하게됩니다. REST API 또는 프로그램이 데이터 모델을 사용하는 방법