JUnit 4 vs TestNG-업데이트 2013-2014 [닫힘]

JUnit 4와 TestNG는 비교가 가능했습니다. 두 테스트 프레임 워크의 장단점은 무엇입니까?

나는 오늘 TestNG와 JUnit4를 비교하고 있었는데, 테스트 프레임 워크에 대한 나의 제한된 경험으로 지적 할 수있는 가장 큰 장점은 TestNG가 데이터 제공자 개념으로 매개 변수화 된 테스트를 처리하는 더 우아한 방법을 가지고 있다는 것입니다.

JUnit4로 말할 수있는 한 테스트하려는 매개 변수 세트마다 별도의 테스트 클래스를 만들어야합니다 (으로 실행 @RunWith(Parameterized.class)). TestNG를 사용하면 단일 테스트 클래스에 여러 데이터 제공자가있을 수 있으므로 단일 클래스에 대한 모든 테스트를 단일 테스트 클래스에도 유지할 수 있습니다.

지금까지 JUnit4보다 TestNG의 이점으로 지적 할 수있는 유일한 점입니다.

Intellij IDEA에는 TestNG 및 JUnit에 대한 지원이 포함되어 있습니다. 그러나 Eclipse는 기본적으로 JUnit 만 지원하며 작동하려면 TestNG 플러그인이 설치되어 있어야합니다.

그러나 TestNG에서 발생한 더 성가신 문제 PowerMockTestCase는 PowerMock을 사용하여 테스트에서 종속성을 모의하는 경우 테스트 클래스를 확장해야한다는 것 입니다. 분명히 특별한 방법을 통해 또는 testng.xml스위트 정의 를 통해 PowerMock을 사용할 때 테스트 프레임 워크가 알아야하는 객체 팩토리를 구성하는 방법이 있지만 지금은 깨진 것 같습니다. 나는 테스트 클래스가 테스트 프레임 워크 클래스를 확장하는 것을 싫어한다.

PowerMock을 사용하지 않는다면 이것은 당연히 문제가되지 않지만, 대체로 JUnit4가 더 잘 지원된다는 인상을받습니다.

두 프레임 워크에 대한 나의 경험을 바탕으로 testng에는 JUnit 팀이 몇 년 동안 구현하지 않은 편리한 기능이 몇 가지 있습니다. 이런 이유로 JUnit보다 선호합니다. testng로 변환하는 것은 기본적으로 JUnit의 거의 모든 것을 지원하기 때문에 쉽습니다 (eclipse 용 변환기 플러그인도 있음). 이러한 누락 된 기능으로 인해 JUnit으로 다시 변환하는 것은 그리 좋지 않습니다.

• testng에서 @BeforeClass메소드는 정적이 아니며 테스트 클래스가로드 될 때가 아니라 해당 클래스의 테스트가 실행되기 전에 실행됩니다 (JUnit 동작). 저는 한때 모든 데이터베이스 테스트 (수십 개)가 처음에 데이터베이스를 초기화하는 JUnit 프로젝트를 가지고 있었는데, 이는 매우 멍청한 행동이었습니다. JUnit 커뮤니티에서 이에 대한 많은 논쟁이있었습니다. 요점은 모든 테스트 메소드가 자체 테스트 픽스처를 가져야하므로 인스턴스 변수를 몰래 설정 한 다음 모든 테스트에서 사용할 수 있기 때문에 정적이 아닌 beforeAll 스타일 메소드를 가져서는 안됩니다. 유효하지만 통합 테스트에는 정말 짜증납니다. TestNG는 여기에서 사용자에게 선택권을 제공합니다. Junit은 설계 상 성가신 일이 아닙니다.

• Testng 데이터 공급자는 JUnit에 해당하는 것보다 약간 더 유연합니다. JUnit에서와 같이 전체 클래스에 대해 하나의 크기가 모든 접근 방식에 맞는 대신 입력을 제공해야하는 데이터 제공자 메소드를 테스트별로 지정할 수 있습니다. 따라서 하나의 클래스에서 테스트에 대한 양성 및 음성 사례 데이터 공급자를 가질 수 있습니다. 가지고있어서 아주 좋습니다.

• @Testin testng를 사용 하여 클래스를 마크 업할 수 있습니다. 즉, 모든 공용 메서드는 테스트입니다. Junit에서는 @Test모든 방법에 복사 / 붙여 넣기를해야합니다 .

둘 다에 대한 성가심은 hamcrest가 JUnit과 번들로 제공되는 방식과 JUnit이 testng와 함께 번들로 제공되는 방식입니다. Maven에는이 문제가없는 대체 항아리가 있습니다.

두 프레임 워크에 대한 나의 큰 걱정은 둘 다 진화를 멈춘 것처럼 보인다는 것입니다. 릴리스 빈도가 점점 줄어들고 주목할만한 기능이 점점 줄어들고 있습니다. 예를 들어 전체 BDD 운동은 두 프레임 워크에 거의 영향을 미치지 않은 것으로 보입니다. 또한 JUnit은 위에 나열된 대부분을 채택했을 수 있습니다. JUnit이 이러한 것들을 구현할 수없는 기술적 이유가 없습니다. JUnit 뒤에있는 사람들은 이러한 것들을 구현하지 않기로 선택합니다. 두 프로젝트 모두 미래 방향에 대한 비전이 부족한 것으로 보이며 지난 몇 년간 사소한 조정 만하면서 기뻐하는 것 같습니다.

TestNG를 JUnit으로 전환해야하는 좋은 이유를 찾고 있었고 Tomek Kaczanowski가이 질문을 매우 잘 다루는 슬라이드를 발견 했습니다 . Tomek은 개발자와 테스터가 매우 존경하는 것으로 보이는 Practical Unit Testing 책의 저자입니다 .

Java / Scala 프로젝트에서 작업하고 Gradle을 선택한 빌드 도구 인 경우 ScalaTest프레임 워크는 JUnitRunner스칼라 테스트 만 실행 하면 됩니다. 즉, 다음 중 하나를 선택할 수 있습니다.

• Java JUnit 테스트 + JUnitRunner로 실행되는 Scala 테스트 => Gradle 통합 향상
• Java testNG 테스트 + Scala 테스트는 Scala Runner => Poor Gradle Integration으로 실행됩니다. scala 테스트 러너는 Gradle의 관점에서 볼 때 단일 대량 작업이기 때문입니다.

Mockito를 모의 프레임 워크로 사용할 수 있습니다. TestNG와 잘 통합됩니다. TestNG와 함께 Mockito를 사용하기 위해 클래스를 확장 할 필요가 없습니다. 테스트 코드는 이러한 방식으로 덜 결합되며 어떤 이유로 든 다른 조롱 프레임 워크를 사용해야하는 경우 쉽게 수행 할 수 있습니다.

간단히 말해서 ..

범위가 세부적인 단위 테스트로 제한되어 있고 그 사이에 종속성이없는 경우 JUnit을 사용할 수 있습니다.

스코프에 종속성 및 테스트 간 데이터 (매개 변수) 공유가 필요하거나 필요하지 않을 수있는 기능 테스트가 필요한 경우 TestNG를 선택합니다. 또한 TestNG는 JUnit과 유사한 단위 테스트를 수행 할 수 있습니다. 따라서 단위 테스트 모음과 기능 테스트 모음을 가질 수 있습니다.