ScalaTest와 Scala Specs 단위 테스트 프레임워크의 차이점은 무엇입니까?
https://stackoverflow.com/questions/2220815
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian해결책
Specs와 ScalaTest는 둘 다 만족스러운 사용자에게 좋은 도구이지만 여러 면에서 다릅니다.Scala의 주요 테스트 도구로 하나를 선택하고 싶을 수도 있지만 두 가지 모두를 사용할 수 있으므로 다른 하나를 포기할 필요는 없습니다.ScalaTest를 좋아한다면 FeatureSpec 예를 들어 구문 및 사양의 Mockito 구문을 사용하면 두 jar 파일을 모두 클래스 경로에 넣고 동시에 사용할 수 있습니다.여기서는 사양과 ScalaTest 사이에서 발견한 주요 디자인 철학의 차이점을 포착해 보겠습니다.
아마도 도구 간의 주요 철학적 차이점은 사양이 BDD(행동 중심 개발)용으로 설계된 반면 ScalaTest는 더 일반적이라는 점일 것입니다.ScalaTest는 BDD를 포함하여 테스트 클래스에서 선호하는 동작을 얻기 위해 함께 혼합할 수 있는 특성을 제공하며, 다른 것을 원하는 경우 자신만의 동작을 쉽게 정의할 수도 있습니다.
ScalaTest는 다음을 통해 BDD를 지원합니다. Spec, FeatureSpec, WordSpec, FlatSpec, 그리고 GivenWhenThen 특성을 가지고 있으며, 멋진 일치 구문을 얻기 위해 혼합할 수 있는 특성도 있습니다."should"를 좋아한다면 ShouldMatchers를 섞으세요."must"를 좋아한다면 섞어서 사용하세요 MustMatchers.그러나 BDD를 좋아하지만 매처 구문이 마음에 들지 않으면 매처 특성을 혼합하지 않고 ScalaTest의 Spec 특성 중 하나를 사용할 수 있습니다.Specs에는 확장하는 사양 클래스가 있으며, 일치자 표현식에 "must"라는 단어를 사용해야 합니다.여기서 분명한 철학적 차이점은 ScalaTest가 훨씬 더 많은 선택권을 제공한다는 것입니다.이 선택 공간을 더 쉽게 탐색할 수 있도록 여기에 의사결정 트리를 제공합니다.
http://www.scalatest.org/quick_start
ScalaTest와 사양 간에 일치자 구문도 다릅니다.ScalaTest에서 나는 연산자 표기법으로 어디까지 갈 수 있는지 알아보려고 노력했고, 단어 사이에 공백이 있는 영어 문장과 매우 유사하게 읽는 일치 표현으로 끝났습니다.사양 일치자 구문은 낙타 표기법과 함께 단어를 더 많이 실행합니다.
Specs에는 ScalaTest보다 더 많은 matcher가 있으며 이는 디자인 태도의 차이를 반영한다고 생각합니다.실제로 제가 만들고 출시를 고려한 일치자 구문의 2/3 정도를 줄였습니다.향후 릴리스에서는 더 많은 matcher를 추가할 예정이지만, 추가하기 전에 사용자가 실제로 원하는 것이 무엇인지 확인하고 싶었습니다.그러나 ScalaTest의 매처에는 동적 속성 매처 구문이 포함되어 있어 이러한 여유 부분을 일부 차지합니다.예를 들어 Specs에서 다음과 같이 쓸 수 있습니다. java.io.File:
file must beDirectory
그러면 isDirectory 그리고 그것이 사실인지 확인하세요.ScalaTest에는 특별한 매처가 없습니다. java.io.Files 현재는 ScalaTest에서는 다음과 같은 동적 검사를 사용할 수 있습니다.
file must be a ('directory)
이후에 기호를 전달할 때마다 be, 리플렉션을 사용하여 (이 경우) 이름이 지정된 메서드나 필드를 찾습니다. directory 또는 이름이 지정된 메서드 isDirectory.이를 정적으로 만드는 방법도 있습니다. BePropertyMatcher (보통 2~3줄의 코드만 필요합니다.)그래서 기본적으로 ScalaTest에서는 더 적은 API로 더 많은 기능을 제공하려고 노력합니다.
사양과 Scalatest의 또 다른 일반적인 디자인 태도 차이는 암시 적 변환과 관련이 있습니다.기본적으로 ScalaTest를 사용할 때 암시적 변환은 하나만 얻습니다. === 모든 것에 대한 연산자.(필요한 경우 코드 한 줄로 이 암시적 변환을 "해제"할 수 있습니다.그렇게 해야 하는 유일한 이유는 자체적인 기능이 있는 것을 테스트하려는 경우입니다. === 연산자를 사용하면 충돌이 발생합니다.) ScalaTest는 다른 많은 암시적 변환을 정의하지만 이를 사용하려면 특성을 혼합하거나 가져오기를 수행하여 코드에 명시적으로 "초대"해야 합니다.수업을 연장할 때 Specification 사양에서는 기본적으로 수십 개의 암시적 변환이 발생한다고 생각합니다.이것이 실제로 얼마나 중요한지는 잘 모르겠지만 사람들은 자신의 암시적 코드를 사용하는 코드를 테스트하고 싶어할 것이며 때로는 테스트 프레임워크의 암시적 코드와 프로덕션 코드의 암시적 코드 사이에 충돌이 있을 수 있다고 생각합니다.그런 일이 발생하면 사양보다 ScalaTest에서 문제를 해결하는 것이 더 쉬울 수 있다고 생각합니다.
제가 발견한 설계 태도의 또 다른 차이점은 운영자에 대한 편안함입니다.내가 가진 한 가지 목표는 ScalaTest를 사용하는 다른 사람의 테스트 코드를 보는 프로그래머가 ScalaTest 문서에서 아무것도 찾아보지 않고도 그 의미가 무엇인지 추측할 수 있다는 것이었습니다.나는 ScalaTest 클라이언트 코드가 명확해지기를 원했습니다.목표가 드러난 한 가지 방법은 ScalaTest가 연산자에 대해 매우 보수적이라는 것입니다.ScalaTest에서는 5개의 연산자만 정의합니다.
===, 이는 같음을 의미합니다.>, 이는 다음보다 크다는 것을 의미합니다.<, 미만>=, 크거나 같음<=, 작거나 같습니다.
그게 다야.그래서 이러한 것들은 의미하는 바와 거의 비슷해 보입니다.다른 사람의 코드에서 본 경우:
result should be <= 7
내 희망은 당신이 그것이 무엇인지 추측하기 위해 API 문서를 실행할 필요가 없다는 것입니다. <= 수단.대조적으로, 운영자의 경우 스펙이 훨씬 더 자유로워집니다.아무 문제가 없지만 차이점이 있습니다.연산자는 코드를 더 간결하게 만들 수 있지만 다음과 같은 것을 발견하면 문서를 확인해야 할 수도 있다는 단점이 있습니다. ->-, >>, |, |>, !, 또는 ^^^ (모두 사양에서 특별한 의미를 가짐)을 동료의 테스트 코드에 추가하세요.
또 다른 철학적 차이점은 픽스처를 공유해야 할 때 ScalaTest에서 기능적 스타일을 사용하는 것을 약간 더 쉽게 만들려고 노력하는 반면 Specs는 기본적으로 전통을 이어간다는 것입니다. setUp 그리고 tearDown 각 테스트 전에 변수를 재할당하는 JUnit에서 대중화된 접근 방식입니다.그러나 그런 방식으로 테스트하고 싶다면 ScalaTest에서도 매우 쉽습니다.그냥 섞어서 드시면 됩니다 BeforeAndAfter 특성.
ScalaTest에 대한 더 많은 통찰력을 얻으려면 2009 Devoxx 컨퍼런스에서 제가 제공한 "Get Higher with ScalaTest" 프레젠테이션을 여기에서 시청할 수 있습니다.
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about
다른 팁
주요 차이점은 (주로 사양 관점에서 :-)) :
Scalatest는 사양보다 더 많은 "테스트 스타일"을 제공합니다 (각 총알 지점을 방문 할 수 있습니다. 빠른 시작 각 스타일에 대한 자세한보기를 얻는 페이지)
Scalatest 및 Spec에는 다른 매칭 세트가 있습니다. 당신은 그것들을 비교할 수 있습니다 여기 Scalatest와 여기 사양의 경우. 이 측면에서 사양은 사양을 작성할 때 원하는 작은 기능이 많이 있습니다 : XML 매칭, 매치 업체 구성 (매치자를 변환하여 매칭을 재사용하는 쉬운 방법), 정확한 실패, 긴 문자열의 상세한 차이점, .. .
Mockito는 사양에서 훌륭한 BDD 지원을 받았습니다. 모키토
사양이 있습니다 데이터 가능 일종의 작은 예제를 일종의 테이블로 그룹화 할 수 있습니다 (테이블 구분 자로 사용되는 연산자를 참을 수있는 경우)
사양에서는 성욕으로 중첩 된 예제를 정의하고 자동으로 정리 모든 수준에서
이것은 확실히 매우 부분적이고 편향된 비교이며 다른 많은 차이가 존재합니다 (그리고 라이브러리는 여전히 진화하고 있습니다 ...).
하루가 끝나면 실제로 테스트/지정 스타일에 달려 있다고 생각합니다. 간단한 경우 (간단한 사양 구조, 설정, 기대치 ...) 두 라이브러리가 매우 유사하게 나타납니다. 그렇지 않으면, 둘 다 일을 어떻게 해야하는지에 대해 생각합니다. 이것의 마지막 예로는 태깅을 볼 수 있습니다. Scalatest 그리고에서 명세서.
이게 도움이 되길 바란다.
내가 아는 한, 고도로 전문화 된 몇 가지 기능을 제외하고 스타일에 따라 개인 취향에 달려 있습니다.
IDE 지원은 또 다른 요점 일 수 있습니다
나는 Junit을 통해 Eclipse와 함께 일하기 위해 사양을 얻으려고 노력했으며 공식 솔루션이 약간 "해킹"이라는 것을 알았습니다. 사양 설정 : http://code.google.com/p/specs/wiki/runningspecs#run_your_specification_with_junit4_in_eclipse
Scalatest의 통합 (주니트를 통한)은 약간 덜 해킹 된 것 같습니다. 그럼에도 불구하고, 나는 주니트와 자바뿐만 아니라 일할도 없었습니다.
Scalatest 설정 : http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse
하나의 의사 결정 요소가 컴파일 시간이면 Scalatest가 더 잘 수행되는 것 같습니다.
우리는 현재 프로젝트에서 Specs2를 사용하고 있지만 테스트에서 컴파일 시간이 느리게 고통 받고 있습니다. 방금 Scalatest로 이동하는 데 POC를 마치고 일부 소스에서 2 개의 프레임 워크를 전환하여 컴파일 타임이 약 0.82의 계수로 떨어졌습니다.
