ScalaTest와 Scala Specs 단위 테스트 프레임 워크의 차이점은 무엇입니까?

ScalaTest와 Scala Specs 단위 테스트 프레임 워크의 차이점은 무엇입니까?

---

둘 다 스칼라로 작성된 스칼라 용 BDD (Behavior Driven Development) 가능 단위 테스트 프레임 워크입니다. 그리고 스펙 은 ScalaTest 프레임 워크를 포함 할 수도 있습니다 . 그러나 사양은 ScalaTest가 제공하지 않는 기능을 제공합니까? 차이점은 무엇입니까?

---

Specs와 ScalaTest는 모두 만족스러운 사용자에게는 유용한 도구이지만 몇 가지면에서 다릅니다. 스칼라에서 테스트 도구로 하나를 선택하길 원하지만 둘 다 사용할 수 있기 때문에 다른 도구를 포기할 필요는 없습니다. FeatureSpec예를 들어 ScalaTest의 구문과 사양의 Mockito 구문이 마음에 들면 두 jar 파일을 모두 클래스 경로에 넣고 동시에 사용할 수 있습니다. 여기에서는 사양과 ScalaTest에서 발견 한 주요 디자인 철학의 차이점을 알아 봅니다.

아마도 툴들 사이의 주요 철학적 차이점은 스펙이 행동 중심 개발 (BDD)을 위해 설계되었지만 ScalaTest가 더 일반적이라는 것입니다. ScalaTest는 BDD를 포함하여 테스트 클래스에서 선호하는 동작을 얻기 위해 함께 혼합 할 수있는 특성을 제공하며, 다른 것을 원할 경우 자신의 동작을 쉽게 정의 할 수도 있습니다.

를 통해 ScalaTest 지원 BDD 그것의 Spec, FeatureSpec, WordSpec, FlatSpec, 및 GivenWhenThen특성, 또한 당신이 좋은 정규 구문을 얻을 수에 혼합 할 수 있다는 특징을 가지고있다. 당신이 "해야한다"를 좋아한다면, 당신은 ShouldMatchers에서 섞는다. 당신이 "필수"를 좋아한다면, 당신은 혼합 MustMatchers합니다. 그러나 BDD를 좋아하지만 매처 구문을 좋아하지 않는 경우에는 매처 특성과 혼합하지 않고 ScalaTest의 Spec 특성 중 하나를 사용할 수 있습니다. Specs에는 확장하는 Specification 클래스가 있으며, 정규 표현식에서 "must"라는 단어를 사용해야합니다. 여기서 명백한 큰 철학적 차이는 ScalaTest가 더 많은 선택을 제공한다는 것입니다. 이 선택 영역을 쉽게 탐색 할 수 있도록 여기에 의사 결정 트리를 제공합니다.

http://www.scalatest.org/quick_start

Matcher 구문은 ScalaTest와 사양 간에도 다릅니다. ScalaTest에서 나는 연산자 표기법으로 얼마나 멀리 갈 수 있는지 알아 내려고 단어 사이에 공백이있는 영어 문장과 매우 ​​흡사 한 일치 표현식으로 끝났습니다. Specs matcher 구문은 camel case와 함께 단어를 더 많이 실행합니다.

스펙은 ScalaTest보다 더 많은 매칭 기능을 가지고 있으며, 디자인 태도의 차이를 반영한다고 생각합니다. 실제로 빌드하고 릴리스로 고려한 matcher 구문의 2/3 정도를 잘라 냈습니다. 다음 릴리스에서는 더 많은 매처를 추가 할 예정이지만 추가하기 전에 사용자가 실제로 무언가를 원한다는 것을 알고 싶었습니다. 그러나 ScalaTest의 matcher에는 동적 속성 matcher 구문이 포함되어 있습니다. 예를 들어 Specs에서는 다음에 쓸 수 있습니다 java.io.File.

file must beDirectory

이것은를 호출하고 isDirectory그것이 사실인지 확인합니다. ScalaTest에는 java.io.Files현재 특별한 매 처가 없지만 ScalaTest에서는 다음과 같이 동적 검사를 사용할 수 있습니다.

file must be a ('directory)

after be에서 심볼을 전달할 때마다 리플렉션을 사용하여 (이 경우) 이름의 메소드 또는 필드 directory또는 이름이 지정된 메소드를 찾습니다 isDirectory. BePropertyMatcher(일반적으로 2 또는 3 줄의 코드 만 필요) 을 정의하여이를 정적으로 만드는 방법도 있습니다 . 기본적으로 ScalaTest에서는 더 적은 API로 더 많은 기능을 제공하려고합니다.

사양과 ScalaTest의 또 다른 일반적인 디자인 태도 차이는 암시 적 변환과 관련이 있습니다. 기본적으로 ScalaTest를 사용하면 ===연산자를 모든 것에 적용 하는 암시 적 변환이 하나만 제공됩니다 . (필요한 경우 한 줄의 코드로이 암시 적 변환을 "끄기"할 수 있습니다. 그렇게해야하는 유일한 이유는 자체 ===연산자 가있는 무언가를 테스트하려고 할 때 충돌이 발생하기 때문입니다. ) ScalaTest는 다른 많은 암시 적 변환을 정의하지만이를 사용하려면 특성을 혼합하거나 가져 오기를 통해 코드에 명시 적으로 "초대"해야합니다. 수업을 연장 할 때Specification스펙에서는 기본적으로 수십 개의 암시 적 변환을 얻는다고 생각합니다. 실제로 이것이 얼마나 중요한지 잘 모르겠지만 사람들이 자신의 암시 적을 사용하는 코드를 테스트하려고 할 때가 있고 때로는 테스트 프레임 워크의 암시 적과 프로덕션 코드의 암시 적간에 충돌이있을 수 있다고 생각합니다. 그런 일이 발생하면 사양보다 ScalaTest의 문제를 해결하는 것이 더 쉽다고 생각합니다.

내가 알아 차린 디자인 태도의 또 다른 차이점은 운영자의 편안함입니다. 내가 한 목표는 ScalaTest를 사용하는 다른 사람의 테스트 코드를 보는 모든 프로그래머가 ScalaTest 설명서에서 아무것도 찾지 않고 그 의미가 무엇인지 추측 할 수 있다는 것입니다. ScalaTest 클라이언트 코드를 확실하게 삭제하고 싶었습니다. 목표가 드러나는 한 가지 방법은 ScalaTest가 운영자에 대해 매우 보수적이라는 것입니다. ScalaTest에는 5 개의 연산자 만 정의합니다.

• ===이며 이는
• >보다 큼
• <이하
• >=보다 크거나 같음
• <=보다 작거나 같습니다.

그게 다야. 이런 것들이 의미하는 것처럼 보입니다. 다른 사람의 코드에서 볼 경우 :

result should be <= 7

My hope is that you won't need to run to the API documentation to guess what that <= means. By contrast, specs is much freer with operators. Nothing wrong with that, but it is a difference. Operators can make code more concise, but the tradeoff is you may have to run to the documentation when you find things like ->-, >>, |, |>, !, or ^^^ (which all have special meanings in Specs) in your colleague's test code.

One other philosophical difference is that I do try and make it just slightly easier in ScalaTest to use a functional style when you need to share a fixture, whereas Specs by default continues the tradition of the setUp and tearDown approach popularized by JUnit, in which you reassign vars before each test. However if you want to test that way, it is also very easy in ScalaTest. You just need to mix in the BeforeAndAfter trait.

For more insight into ScalaTest, you can watch the "Get Higher with ScalaTest" presentation I gave at the 2009 Devoxx conference here:

http://parleys.com/play/514892260364bc17fc56bde3/chapter0/about

---

The main differences are (mostly from a specs point of view :-) ):

• ScalaTest provides more "testing styles" than specs (you can visit each bullet point on the quick start page to get a detailed view on each style)

• ScalaTest and specs have a different set of matchers. You can compare them here for ScalaTest and here for specs. On that side of things, specs has a lot of small features that you may like when writing your specification: xml matchers, matchers composition (an easy way to reuse matchers by transforming them), precise failures, detailed differences for long strings, ...

• Mockito has been given a nice BDD support in specs: Mockito

• specs has DataTables which allow to group a lot of small example in a sort of table (if you can stand operators being used as the table delimiters)

• In specs, you can define examples which are nested as libidum and automatically cleaned-up at every level

This is certainly a very partial and biased comparison and many other differences exist (and the libraries are still evolving, ...).

At the end of the day I think that it really depends on your testing/specifying style. If it's simple (simple specification structure, setups, expectations, ...) then both libraries will appear very similar. Otherwise, both have their take on how things should be done. As a last example of this you can have a look at tagging: in ScalaTest and in specs.

I hope this helps.

---

As far as I know, barring a few highly specialized features, it comes down to personal preference according to the style.

---

IDE support may be another point

I've been trying to get Specs to work with Eclipse through JUnit, and I found the official solution to be a bit "hacky". Specs setup: http://code.google.com/p/specs/wiki/RunningSpecs#Run_your_specification_with_JUnit4_in_Eclipse

ScalaTest's integration (also through JUnit) with seems a bit less hacky. Still, I haven't got any of them to work as well as JUnit and Java.

ScalaTest setup: http://groups.google.com/group/scalatest-users/web/running-scalatest-from-eclipse

---

If one decision factor is the compile time, scalatest seems to perform better.

We're currently using specs2 in our project, but suffer from slow compile times in tests. I just finished a POC on moving to scalatest and saw compile times drop by a factor of about 0.82 just by switching the 2 frameworks in some of our sources.

참고URL : https://stackoverflow.com/questions/2220815/what-s-the-difference-between-scalatest-and-scala-specs-unit-test-frameworks