Drawbacks of TestNG compared to jUnit? [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_如何学JAVA

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I'm familiar with jUnit, and heard TestNG might be a solution to some of jUnit's annoyences - e.g. its insistence to create a separate instance of the test class per test, thus forcing me to use static field for objects I want to reuse between tests.

(Let's say you agree with me that this is a drawback, and not turn this question to something it's not)

What I'm asking here, is what drawbacks does TestNG have, compared to jUnit? Why not use TestNG, assuming this is a new project and there isn't any migration cost?

---

I'm the creator of TestNG. I'm not going to weigh in since I'm obviously biased, but I'm happy to answer any question you might have about TestNG.

Andy: thanks for your comment. FYI (you probably already know that but maybe the original poster doesn't), there is a TestNG Eclipse plug-in (which I develop in parallel to TestNG).

---

I personally have not encountered any significant drawbacks compared to JUnit.

At the start of a new project, my team switched to TestNG and had no regrets. TestNG is more powerful and supports broader usage than unit tests.

Some tools support JUnit but not TestNG. These are tools that I have not yet needed. For example:

• Google's CodePro Analytix supports generation of JUnit unit tests.
• The Eclipse IDE for RCP development supports run/debug configurations for "JUnit plug-in tests."

---

Being a huge supporter of TestNG I still see it is treated as being number 2 by tools authors. Many tools and libraries support JUnit from the very beginning, but you have to wait till they also implement support for TestNG. This might be a serious drawback if you plan to use some latest buzzing technology.

Over the years situation improved a lot. For example this used to be an issue with Spring, Gradle, or Maven Surefire but is no longer a problem because they all support TestNG now. Also all IDEs are treating both frameworks equally.

So, make sure the other technologies you plan to use play nicely with TestNG. This is rarely a problem, but still better make sure of it ahead.

---

For me the biggest problem is an integration with spring. I do not like to extend TestNg classes and write code like this:

@Test
@ContextConfiguration(locations = { "classpath:spring-test-config.xml" })
public class TestSpring extends AbstractTestNGSpringContextTests {

Because usually I have my own hierarchy of test classes. This was the main reason why I stopped using TestNg.

I must agree that parameterized test was very attractive for me. But they can be easily replaced with junit data-provider.

https://github.com/TNG/junit-dataprovider/wiki/Getting-started