Discussions

News: Article: Migrating to TestNG

  1. Article: Migrating to TestNG (21 messages)

    TestNG is a promising new testing framework that addresses many of the shortfalls of JUnit. However, most projects have hundreds, if not thousands of JUnit tests already written. This article by Hani Suleiman shows you how you can migrate to TestNG without a massive conversion effort.

    Read Migrating to TestNG

    Threaded Messages (21)

  2. Article: Migrating to TestNG[ Go to top ]

    This is going to be fun. 200+ posts on this one.
  3. Article: Migrating to TestNG[ Go to top ]

    Ok, here goes...

    JUnit blows! TestNG r0x0rs!

    That should get the ball rolling. :)

    Oh, and what's with all this Hani being useful crap? He's supposed to just complain. I use to respect him because he had clearly discovered his purpose in life: to bitch. Now he's gone and done something, dare I say...useful. First an IntelliJ plugin and now this. All my heroes are gone. :(
  4. Article: Migrating to TestNG[ Go to top ]

    Oh, and what's with all this Hani being useful crap?

    Hani has actually always been a big producer of various open-sores crap, mainly at the now pretty much defunct http://www.opensymphony.com/.
  5. Article: Migrating to TestNG[ Go to top ]

    Hani has actually always been a big producer of various open-sores crap, mainly at the now pretty much defunct http://www.opensymphony.com/.

    Pot, Kettle. Kettle, Pot. ;)

    Since when is opensymphony.com defunct? Been there lately? I know for a fact WebWork is actively developed.
  6. Article: Migrating to TestNG[ Go to top ]

    Can somebody clarify what the so called shortcommings of JUnit are?
  7. Why testng?[ Go to top ]

    It is more about the extra features provided by testng.
    If you dont need them then using JUnit is fine.

    Things that I like about testng are: groups, parameters and
    finer control over when things get executed. I also like
    the fact that my tests are simple POJOs but that is not that
    big of a deal, since in practise all that means is that I
    have one less 'compile-time' dependency. Although my tests
    are still 'sort-of' coupled to testng through my javadoc
    comments.
    Can somebody clarify what the so called shortcommings of JUnit are?
  8. Article: Migrating to TestNG[ Go to top ]

    Can somebody clarify what the so called shortcommings of JUnit are?

    I try to think about it less of shortcomings and more of what it was designed to do.

    JUnit was designed to perform unit tests. TestNG was designed to make it easy to do all sorts of testing. Most of my testing is contract based functional testing, which TestNG allows me to perform very well with using dynamic test cases as opposed to the static ones JUnit supports so well.

    I did get JUnit, evenutally, to support what I needed to do, but the hacking of the framework was unacceptable and didn't meet all of the requirements I had. TestNG supported what I needed to do.

    I blogged about it a few weeks back after a similar thread here.

    http://twofourone.blogspot.com/2005/07/java-testing-hissy-fits-or-how-i.html
  9. Article: Migrating to TestNG[ Go to top ]

    Can somebody clarify what the so called shortcommings of JUnit are?
    I explained some of my gripes in several blog entries:

    http://jroller.com/page/cbeust/20030425
    http://www.jroller.com/page/cbeust/20030317
    http://www.beust.com/weblog/archives/000173.html

    Anyway, you don't really need to agree with those but this shouldn't stop you from taking a look at the features that TestNG offers and decide for yourself if it serves your testing needs better than JUnit (and if it does but you want to stick with JUnit, you can always request these features from the JUnit team).

    --
    Cedric
  10. Article: Migrating to TestNG[ Go to top ]

    Actually I just realized that my main gripe with JUnit is not listed above. It can be found here:

    http://www.beust.com/weblog/archives/000082.html

    --
    Cedric
  11. Article: Migrating to TestNG[ Go to top ]

    This link http://www.beust.com/weblog/archives/000082.html immediatly raises the question: "Why do I need a jdbc connection in my test case?" Are we testing a class or are we testing a jdbc driver? I rather assume that the jdbc driver does its job correct. So mock the darn thing and verify that the correct calls are made to the driver.

    So in my opinion you want to test to much at once.
  12. Article: Migrating to TestNG[ Go to top ]

    This link http://www.beust.com/weblog/archives/000082.html immediatly raises the question: "Why do I need a jdbc connection in my test case?" Are we testing a class or are we testing a jdbc driver? I rather assume that the jdbc driver does its job correct. So mock the darn thing and verify that the correct calls are made to the driver. So in my opinion you want to test to much at once.

    The implication being that tests should only be unit tests?

    There is more to the world than just unit tests. You may have heard of, for example, integration tests, end-to-end tests, etc. In such scenarios you actually want real objects, not mocks, because you are testing full-through behavior of the system.

    Conceptually this is somewhat different from unit testing, but in practical terms you want to automate as many of your tests as you can, from low-level single unit tests all the way up to complex integration suites.

    Sure, unit tests should be automated. But why not other tests as well? You seem surprised that someone would write a test that requires a JDBC connection. Why? Is the concept of automated integration and end-to-end processing tests that novel?
  13. Article: Migrating to TestNG[ Go to top ]

    This link http://www.beust.com/weblog/archives/000082.html immediatly raises the question: "Why do I need a jdbc connection in my test case?" Are we testing a class or are we testing a jdbc driver? I rather assume that the jdbc driver does its job correct. So mock the darn thing and verify that the correct calls are made to the driver. So in my opinion you want to test to much at once.
    Why not use code that will be as close as possible as your production code?

    JDBC drivers are complex pieces of software and in my experience, you really want to include them in your testing suite or you run the risk of ending up with a false positive (all your tests pass but your production code fails).

    I really don't understand this obsession with mocks, especially with JDBC drivers, which are plenty fast. There is also the fact that mocks force you to duplicate your code base with the risk of introducing bugs of your own, but that's a separate topic.

    --
    Cedric
    http://testng.org
  14. Article: Migrating to TestNG[ Go to top ]

    Actually I just realized that my main gripe with JUnit is not listed above. It can be found here:http://www.beust.com/weblog/archives/000082.html-- Cedric

    If I understand the complaint correctly, it is the default behavior of the test runner, but anyone can easily write a custom test runner.

    when I implemented jmeter sampler for JUnit, I did exactly that. rather than use the stock test runner, I wrote the sampler to only create an instance of the class once per thread. In a multi-threaded environment like JMeter, which is used for both functional and load testing, creating a new instance every single time doesn't make sense.

    like wise, methods like oneTimeSetUp and oneTimeTearDown can't be treated the same way in a multi-threaded environment, so the sampler i wrote doesn't call those methods for every single instance of a testcase.

    instead, I made it so users can create a tread group and call oneTimeSetUp and TearDown in a separate thread group for all classes being tested. the limitations of junit are real, but my opinion is it isn't fatally flawed or broken. it does make complex test scenarios harder than one would like.

    peter
  15. Article: Migrating to TestNG[ Go to top ]

    Actually I just realized that my main gripe with JUnit is not listed above. It can be found here:http://www.beust.com/weblog/archives/000082.html-- Cedric
    If I understand the complaint correctly, it is the default behavior of the test runner, but anyone can easily write a custom test runner.
    Actually, no: it's a design feature of JUnit.

    JUnit was designed so that it would re-instantiate your test class *before* every test method invocation.

    Sure, you can create your own runner (which seems to be the traditional way to do things JUnit was not supposed to do in the first place), but then you run the risk of seeing testers write code with the assumption that a new instance will be created every time, and chaos will ensue.

    I have never agreed with this design decision (which a lot of JUnit users don't know about, by the way) because it is completely counter-intuitive to any OO knowledge that everybody has and it also forces you go out of your way if you want to maintain state in-between invocations (i.e. using statics).
    methods like oneTimeSetUp and oneTimeTearDown can't be treated the same way in a multi-threaded environment
    The absence of such a functionality
    methods like oneTimeSetUp and oneTimeTearDown can't be treated the same way in a multi-threaded environment
    The absence of these two methods is also a glaring hole in JUnit, in my opinion, which is why TestNG lets you define configuration methods that get called:

    - around methods (similar to setUp()/tearDown())
    - around classes
    - around tests
    - around suites
    - around groups

    Pick whatever granularity suits you. And you shouldn't have to create a new TestRunner for such an essential functionality.
    the limitations of junit are real, but my opinion is it isn't fatally flawed or broken. it does make complex test scenarios harder than one would like.peter
    Agreed.

    --
    Cedric
    http://testng.org
  16. Article: Migrating to TestNG[ Go to top ]

    Actually, no: it's a design feature of JUnit.

    JUnit was designed so that it would re-instantiate your test class *before* every test method invocation.

    Sure, you can create your own runner (which seems to be the traditional way to do things JUnit was not supposed to do in the first place), but then you run the risk of seeing testers write code with the assumption that a new instance will be created every time, and chaos will ensue.

    I have never agreed with this design decision (which a lot of JUnit users don't know about, by the way) because it is completely counter-intuitive to any OO knowledge that everybody has and it also forces you go out of your way if you want to maintain state in-between invocations (i.e. using statics).

    atleast it's open source and developers can make changes :) All things considered, "features" are necessary evil of writing software. God knows, I've written features that were half baked, which I replaced with better "features" once I realize my errors. Of course, someone will come along and consider the "new feature" is also half baked and ask that I make changes to fit their needs.

    developers never make "wrong assumptions" when writing unit tests. we always write perfect code and perfect unit tests. no one needs to worry about misbehaving tests. that's just fiction.

    peter
  17. Article: Migrating to TestNG[ Go to top ]

    Have you tried to create TestSetup wrapper)

    ---------------------------
    Domingo Sebastian
    SCJP
    http://www.prestigevillas.com
  18. Migrating to TestNG?[ Go to top ]

    Eclipse plugin woks buggy. Yeah, nasty runtime Exceptions.
    Doesn't it works with 3.1 ?

    But Junit features still work well.
    Sad.
  19. Migrating to TestNG?[ Go to top ]

    Eclipse plugin woks buggy. Yeah, nasty runtime Exceptions.Doesn't it works with 3.1 ?But Junit features still work well.Sad.
    Eugene, can you email me the errors you are seeing? (and yes, we are all using the plug-in with 3.1)

    --
    Cedric
    http://testng.org
  20. Spring integration[ Go to top ]

    On a related note, somebody just announced they had a first version of Spring integration with TestNG, which will make migration even easier for Spring users.

    --
    Cedric
    http://testng.org
  21. Re: Spring integration[ Go to top ]

    Here is a link to what Cedric mentioned above

    http://forum.springframework.org/viewtopic.php?t=7903
  22. I'll give more detailed feedback