Specs와 ScalaTest는 모두 만족스러운 사용자에게 좋은 도구이지만 여러면에서 다릅니다. 스칼라의 주요 테스트 도구로 하나를 선택하고 싶겠지 만 둘 다 사용할 수 있기 때문에 다른 하나를 포기할 필요는 없습니다. FeatureSpec예를 들어 ScalaTest의 구문과 사양의 Mockito 구문 을 좋아한다면 두 jar 파일을 클래스 경로에 넣고 동시에 둘 다 사용할 수 있습니다. 여기서는 스펙과 ScalaTest 사이에서 발견 한 주요 디자인 철학의 차이점을 포착하려고합니다.
아마도 도구 간의 주요 철학적 차이점은 사양이 BDD (Behavior-Driven Development) 용으로 설계되었지만 ScalaTest가 더 일반적이라는 것입니다. ScalaTest는 BDD를 포함하여 테스트 클래스에서 선호하는 동작을 얻기 위해 함께 혼합 할 수있는 특성을 제공하며, 다른 것을 원하는 경우 자신의 동작을 쉽게 정의 할 수도 있습니다.
를 통해 ScalaTest 지원 BDD 그것의 Spec, FeatureSpec, WordSpec, FlatSpec, 및 GivenWhenThen특성, 또한 당신이 좋은 정규 구문을 얻을 수에 혼합 할 수 있다는 특징을 가지고있다. "should"가 마음에 들면 ShouldMatchers에서 믹스합니다. "must"를 좋아한다면 MustMatchers. 그러나 BDD를 좋아하지만 matcher 구문이 마음에 들지 않는 경우, matcher 특성을 혼합하지 않고 ScalaTest의 Spec 특성 중 하나만 사용할 수 있습니다. Specs에는 확장하는 Specification 클래스가 있으며 matcher 표현식에서 "must"라는 단어를 사용해야합니다. 여기서 명백한 철학적 차이점은 ScalaTest가 훨씬 더 많은 선택을 제공한다는 것입니다. 이 선택 공간을보다 쉽게 탐색 할 수 있도록 여기에 의사 결정 트리를 제공합니다.
http://www.scalatest.org/quick_start
매처 구문도 ScalaTest와 사양간에 다릅니다. ScalaTest에서 나는 연산자 표기법으로 얼마나 멀리 갈 수 있는지 보려고 노력했고, 단어 사이에 공백이있는 영어 문장과 매우 흡사 한 일치 표현으로 끝났습니다. Specs matcher 구문은 카멜 케이스와 함께 더 많은 단어를 실행합니다.
Specs는 ScalaTest보다 더 많은 matcher를 가지고 있으며 디자인 태도의 차이를 반영한다고 생각합니다. 나는 실제로 내가 구축하고 출시를 고려한 매처 구문의 2/3를 잘라 냈다. 나는 향후 릴리스에서 더 많은 매처를 추가 할 것이지만 추가하기 전에 사용자가 실제로 원하는 것을 알고 있는지 확인하고 싶었습니다. 그러나 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에서 다섯 개의 연산자 만 정의합니다.
===, 즉 같음>, 이는보다 큼을 의미합니다.<,보다 작음>=, 크거나 같음<=, 작거나 같음.
그게 다야. 그래서 이런 것들은 의미하는 것처럼 보입니다. 다른 사람의 코드에 다음이 표시되는 경우 :
result should be <= 7
제 희망은 그것이 <=의미하는 바를 추측하기 위해 API 문서를 실행할 필요가 없다는 것입니다 . 대조적으로 사양은 운영자에게 훨씬 더 자유 롭습니다. 그게 잘못은 아니지만 차이입니다. 운영자가 코드를보다 간결을 할 수 있지만, 트레이드 오프는 같은 물건을 찾을 때 문서를 실행해야 할 수있다 ->-, >>, |, |>, !, 또는 ^^^동료의 테스트 코드에서 (모든 사양에서 특별한 의미를 가지고있는).
또 다른 철학적 차이점은 내가 ScalaTest에서 조명기를 공유해야 할 때 기능적 스타일을 사용하는 것을 약간 더 쉽게 만들려고한다는 것입니다. 반면에 Specs는 기본적 으로 JUnit에서 대중화 한 setUp및 tearDown접근 방식 의 전통을 계속 유지합니다. 각 테스트 전에. 그러나 그런 방식으로 테스트하고 싶다면 ScalaTest에서도 매우 쉽습니다. BeforeAndAfter특성 을 혼합하면 됩니다.
ScalaTest에 대한 자세한 내용은 2009 Devoxx 컨퍼런스에서 제가 발표 한 "Get Higher with ScalaTest"프레젠테이션을 여기에서 볼 수 있습니다.
http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about