Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Java 6

      Description

      TestNG equivalent of AbstractSolrTestCase , without using JUnit altogether .

      New Class created: AbstractSolrNGTest

      LICENSE.txt , NOTICE.txt modified as appropriate. ( TestNG under Apache License 2.0 )

      TestNG 5.9-jdk15 added to lib.

      Justification: In some workplaces - people are moving towards TestNG and take out JUnit altogether from the classpath. Hence useful in those cases.

      1. testng-5.9-jdk15.jar
        833 kB
        Karthik K
      2. SOLR-1212.patch
        14 kB
        Karthik K

        Activity

        Hide
        Karthik K added a comment -

        TestNG 5.9

        Show
        Karthik K added a comment - TestNG 5.9
        Hide
        Shalin Shekhar Mangar added a comment -

        I'm not sure what to do with this. We don't need to ship this with our releases. Perhaps it is best to mark this as "Won't Fix" and link this issue to http://wiki.apache.org/solr/TestingSolr so that people who use TestNG can use this code if necessary.

        Show
        Shalin Shekhar Mangar added a comment - I'm not sure what to do with this. We don't need to ship this with our releases. Perhaps it is best to mark this as "Won't Fix" and link this issue to http://wiki.apache.org/solr/TestingSolr so that people who use TestNG can use this code if necessary.
        Hide
        Karthik K added a comment -

        Keeping this out of the codebase would result in the patch being out of sync with the tree. If there were no licensing restrictions - what is the harm in having this in the tree.

        Show
        Karthik K added a comment - Keeping this out of the codebase would result in the patch being out of sync with the tree. If there were no licensing restrictions - what is the harm in having this in the tree.
        Hide
        Shalin Shekhar Mangar added a comment -

        Keeping this out of the codebase would result in the patch being out of sync with the tree. If there were no licensing restrictions - what is the harm in having this in the tree.

        You wrote this because you needed it at work and I appreciate that you thought about contributing it to Solr. But from Solr's perspective it is not needed and therefore I don't see why we should ship it at all. It is a class that is not used by Solr but would need to be maintained by us if we ship it.

        Show
        Shalin Shekhar Mangar added a comment - Keeping this out of the codebase would result in the patch being out of sync with the tree. If there were no licensing restrictions - what is the harm in having this in the tree. You wrote this because you needed it at work and I appreciate that you thought about contributing it to Solr. But from Solr's perspective it is not needed and therefore I don't see why we should ship it at all. It is a class that is not used by Solr but would need to be maintained by us if we ship it.
        Hide
        Hoss Man added a comment -

        I'm on the fence ...

        i agree it's (probably) useful to TestNG users and i would like to do as much as possible to make it easy for people to use the TestHarness (regardless of how they write tests) but the idea of including it in the release does "smell fishy" if we're not actually using it anywhere in Solr – it may not seem like much overhead to maintain it, but if it never gets used internally then it's not really clear if/when there are problems with it (even Test code needs to be tested to be sure that it's not broken).

        If it's not included in the Solr repository, then it may fall out of sync with Solr – but that's true of any plugin someone writes and hosts on sourceforge, or github, or googlecode – we can advertise that it works with Solr 1.4, and if something changes in Solr 1.5, or Solr 1.6 or Solr 9.7 that breaks it then interested parties are free to update it with new version that does work.

        ...If i knew more about TestNG i might be able to form a stronger opinion like "this is awesome, it's super useful, we should include it" or "this doesn't really provide any value add to users" but I just don't know enough either way.

        Show
        Hoss Man added a comment - I'm on the fence ... i agree it's (probably) useful to TestNG users and i would like to do as much as possible to make it easy for people to use the TestHarness (regardless of how they write tests) but the idea of including it in the release does "smell fishy" if we're not actually using it anywhere in Solr – it may not seem like much overhead to maintain it, but if it never gets used internally then it's not really clear if/when there are problems with it (even Test code needs to be tested to be sure that it's not broken). If it's not included in the Solr repository, then it may fall out of sync with Solr – but that's true of any plugin someone writes and hosts on sourceforge, or github, or googlecode – we can advertise that it works with Solr 1.4, and if something changes in Solr 1.5, or Solr 1.6 or Solr 9.7 that breaks it then interested parties are free to update it with new version that does work. ...If i knew more about TestNG i might be able to form a stronger opinion like "this is awesome, it's super useful, we should include it" or "this doesn't really provide any value add to users" but I just don't know enough either way.
        Hide
        Karthik K added a comment -

        @Shalin , @HossMan - I understand the pain of maintaining this one separate from Junit - but was concerned mostly about this being out of date with the tree.

        As regarding comparison between TestNG vs JUnit - one big advantage is to categorize the tests as different groups in testng and run them separately (especially useful as the code base of solr gets bigger + contrib ). Which is one of the primary reasons (After evaluating both ) - testng was chosen. So - if you guys are not comfortable with the patch - then (as shalin noted) - just make an entry in the wiki and leave this one as such. The code is definitely not big to warrant a sf project / github / google code at this point.

        A better patch would be to refactor existing JUnit Test case so that the testng version minimizes duplication as much as possible.

        Show
        Karthik K added a comment - @Shalin , @HossMan - I understand the pain of maintaining this one separate from Junit - but was concerned mostly about this being out of date with the tree. As regarding comparison between TestNG vs JUnit - one big advantage is to categorize the tests as different groups in testng and run them separately (especially useful as the code base of solr gets bigger + contrib ). Which is one of the primary reasons (After evaluating both ) - testng was chosen. So - if you guys are not comfortable with the patch - then (as shalin noted) - just make an entry in the wiki and leave this one as such. The code is definitely not big to warrant a sf project / github / google code at this point. A better patch would be to refactor existing JUnit Test case so that the testng version minimizes duplication as much as possible.
        Hide
        Karthik K added a comment -

        @HossMan - Interesting thread from stackoverflow - http://stackoverflow.com/questions/153427/is-there-a-junit-testrunner-for-running-groups-of-tests . Not sure - how much of junit has kept up with TestNG recently but TestNG is definitely a notch up (IMHO, of course).

        Show
        Karthik K added a comment - @HossMan - Interesting thread from stackoverflow - http://stackoverflow.com/questions/153427/is-there-a-junit-testrunner-for-running-groups-of-tests . Not sure - how much of junit has kept up with TestNG recently but TestNG is definitely a notch up (IMHO, of course).
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5
        Hide
        Hoss Man added a comment -

        Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.

        email notification suppressed to prevent mass-spam
        psuedo-unique token identifying these issues: hoss20120321nofix36

        Show
        Hoss Man added a comment - Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently. email notification suppressed to prevent mass-spam psuedo-unique token identifying these issues: hoss20120321nofix36
        Hide
        Hoss Man added a comment -

        bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment

        Show
        Hoss Man added a comment - bulk fixing the version info for 4.0-ALPHA and 4.0 all affected issues have "hoss20120711-bulk-40-change" in comment
        Hide
        Robert Muir added a comment -

        rmuir20120906-bulk-40-change

        Show
        Robert Muir added a comment - rmuir20120906-bulk-40-change
        Hide
        Hoss Man added a comment -

        removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certianly be revisted if volunteers step forward)

        Show
        Hoss Man added a comment - removing fixVersion=4.0 since there is no evidence that anyone is currently working on this issue. (this can certianly be revisted if volunteers step forward)

          People

          • Assignee:
            Unassigned
            Reporter:
            Karthik K
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development