단위 테스트를 "기능 계약"으로 사용

Question

유닛 테스트는 설치를 확인하기 위해 소프트웨어 릴리스와 함께 배포됩니다. 즉, 설치를 수행하고 테스트를 실행하고 설치가 성공하면 테스트가 실행됩니다.

저는 프로토 타입 소프트웨어 라이브러리를 고객에게 제공하는 프로젝트에 착수했습니다. 단위 테스트는 각 릴리스의 일부로 제공되며 테스트를 통해 설치를 검증하는 것 외에도 API 테스트를 수행하는 단위 테스트를 릴리스의 사용 방법에 대한 "계약"으로 사용할 계획입니다. 사용자가 유닛 테스트에서 사용한 것과 비슷한 방식으로 릴리스를 사용하면 큰 문제가 발생합니다. 그들이 다른 방법으로 그것을 사용한다면 모든 베팅은 꺼져 있습니다.

아무도 전에 이것을 시도 했습니까? 이것이 좋은 생각인지 나쁜 생각인지에 대한 생각?

편집 : 아래의 답변에서 ChrisA와 Dan이 제기 한 좋은 점을 강조하기 위해 "API를 테스트하는 단위 테스트"를 통합 테스트라고 부르는 것이 좋으며 기능을 설명하기 위해 API와 소프트웨어를 사용하는 것이 더 바람직합니다. 고객 관점에서 소프트웨어의

Answer 1

나에게 좋은 생각이 들립니다. 나는 (우리 모두?) 일상적으로 단위 테스트를 내부적으로 사용합니다. 단위 테스트를 사용하여 아무 것도 깨뜨리지 않았 음을 확인하기 위해 내 API 계약이 변경되지 않았 음을 내재적으로 확인합니다. 당신이 말하는 패션에 그들을 배치하는 것은 단위 테스트의 자연스러운 사용법처럼 보입니다.

Answer 2

민첩한 방법론 : 테스트는입니다. 따라서 이것은 매우 좋은 생각입니다.

Answer 3

실제로 API 사용자로서 매우 유쾌합니다.

이 기술은 실제로 다른 방식으로도 사용할 수 있습니다. "기존"API를 사용하는 경우 단위 테스트를 사용하여 API가 동작한다고 생각하는 방식을 문서화하고 실제로 예상대로 작동하는지 확인합니다 .

Answer 4

나는 이것에 대해 완전히 불타 오르기를 기대하지만, 고객이 염두에 두는 것, 즉 응용 프로그램이 비즈니스 요구 사항을 충족시키는 지 여부에 대해 단위 테스트 세트가 어떤 것을 증명하는지 전혀 이해하지 못합니다.

다음은 예입니다. 우리가 작성한 큰 실수를 수정하기위한 코드 조각 변환이 끝났습니다. 그것은 over-engineering의 고전적인 경우 였고, 변경 사항은 약 12 ​​개의 창 형태와 많은 클래스에 영향을주었습니다.

이제는 며칠이 걸렸습니다. 이제는 훨씬 더 간단 해졌으며, 우리는 무료로 몇 가지 기능을 얻었고, 우리가 필요로하지 못했던 많은 코드를 잃어 버렸습니다.

이러한 형태 중 하나 하나가 완벽하게 작동했습니다. 공용 메소드는 꼭 필요한 작업을 수행했으며 기본 데이터 액세스는 훌륭했습니다.

그래서 모든 단위 테스트가 통과했을 것입니다.

슬프게도, 그들은 회고에서를 제외하고는, 우리가 알지 못했던 잘못된 것을했습니다. 마치 프로토 타입을 제작 한 후에 사용하려고 시도한 후에야 그것이 옳지 않다는 것을 깨달았습니다.

이제 우리는 좀 더 가볍고, 더 차분한 응용 프로그램을 제공합니다.

하지만 잘못 된 사항은 단위 테스트에서 밝혀 내지 못했던 수준에서 잘못되었으므로 설치를 통해 단위 테스트 집합을 배송하는 것이 어떻게 잘못된지를 제외하고는 무엇을하는지 이해하지 못하고 있습니다. 보안.

어쩌면 나는 뭔가를 이해하지 못 하겠지만, 제공되는 테스트와 동일한 수준의 기능인 이 출하되지 않는 한 아무 것도 증명하지 못합니다.

Answer 5

코드에 일련의 사양을 제공하려는 경우 일부 비헤이비어 주도 개발 도구 (nbehave, jbehave, rspec 등)를 조사해야합니다. 이러한 프레임 워크는 주어진/때/다음 구문에서 테스트를 설명하고 자연 언어로 형식화 된 결과를 출력하는 것을 지원합니다. .NET 용 BDD 도구의 예는 nbehave을 참조하십시오. 당신은 BDD here

의 훌륭한 설명을 찾을 수 있습니다 당신이 수용 테스트 프레임 워크 코드와 같은 fit 또는 fitnesse (또는 자바 전용 concordion) 및 제공이 수용 테스트를 사용하여 테스트를 작성하는 또 다른 방법이 될 수있다. fit/fitnesse와 concordion 모두 평범한 HTML 또는 Word 문서에서 테스트를 지정할 수 있습니다.

두 가지 방법 (BDD 또는 수락 테스트 프레임 워크)의 이점은 사용자가 보는 결과가 사람이 읽고 이해할 수 있다는 것입니다.

Answer 6

코드 라이브러리을 발표 할 경우 매우 좋습니다.

사용자가 GUI을 통해서만 상호 작용할 일반 소프트웨어 제품을 릴리스하는 경우 동일한 테스트 수준에서 단위 테스트가 작동하지 않거나 다음과 같은 동작을 평가하는 데 가장 유용한 도구가 아닐 수 있습니다. 귀하의 제품. 정말 좋은 사용자 설명서 (예, 가능합니다)가 더 좋을 수도 있습니다.

Answer 7

테스트에서 요구 사항을 확인합니다.

요구 사항 기능 정의

=> 테스트에서 기능을 확인합니다.

문제는 단위 테스트에서 다룰 수있는 기능 만 검사 할 수 있다는 것입니다. 통합 또는 전체 시스템 테스트가 작동하지 않습니다.

그렇지 않으면 단위 테스트를 통해 기능을 확인하는 것이 TDD의 주요 접근 방식입니다.

Answer 8

Meszaros은 "문서로 테스트합니다"