Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.5.0
    • Component/s: tests
    • Labels:
      None

      Description

      I've put together some tests as a skeletal place to start with Solr tests. I'll add a zip file in a few minutes. They do a really simple ping, one indexes a few documents and searches, and one verifies that we can get to the filterCache statistics.

      This is very preliminary. The zipped up tests run against a locally-built Solr, NOT the one that will be packaged with BigTop. And I haven't a clue how to integrate them with the actual package, (any hints welcome). This is meant as a starting place.

      Of course to be done for real we'll need to create an actual patch, but I'm guessing we'll need to sequence that after the base Solr gets into the packaging, the zip file is meant as a record to build upon when we actually get this all together.

      1. solr_tests.zip
        3 kB
        Erick Erickson
      2. TestSimple.groovy
        5 kB
        Erick Erickson
      3. BIGTOP-736.patch.txt
        21 kB
        Roman Shaposhnik

        Activity

        Hide
        Erick Erickson added a comment -

        Roman:

        I don't see BIGTOP-738 in the patch attached to this JIRA from Oct 30. That patch uses Lucene directly to manipulate an index, can we include that?

        I'll upload a patch for 739 (embedded Solr server) momentarily, assuming my internet doesn't go wonky. That test needs access to SOLR_HOME directory for the example in the stock distro, on my machine for instance it'd be /Users/Erick/apache/4x/solr/example/solr. There's a TODO in the embedded test (739). I notice what looks like setting SOLR_URL as an environment variable, can we do something similar for SOLR_HOME?

        I've also uploaded a new patch for 738 that should be in the right package.

        But that's really an aside. I guess I'm not sure how far to take creating tests. At this point we've hit a bunch of major units of Solr, although extremely shallowly. My personal feeling is that we should just get this in place then expanding them as needed.

        The tests so far are a bit fragile, just something to keep in mind. They use the example installation and manipulate the index there, attempting to clean things up tidily. All well and good, but that makes the state of the index files suspect with more extensive tests. The regular Solr tests have a complicated way of creating temp directories to bypass this problem, but again I think that's for "the future", if we find we need more robustness in the tests. My personal feeling is that we're testing "if everything goes right" here, not "can we handle all the strange cases that could exist".

        So lets add the two JIRAs (738 and 739) and I'll close all that series.

        Thanks so much for doing the hard parts!

        Show
        Erick Erickson added a comment - Roman: I don't see BIGTOP-738 in the patch attached to this JIRA from Oct 30. That patch uses Lucene directly to manipulate an index, can we include that? I'll upload a patch for 739 (embedded Solr server) momentarily, assuming my internet doesn't go wonky. That test needs access to SOLR_HOME directory for the example in the stock distro, on my machine for instance it'd be /Users/Erick/apache/4x/solr/example/solr. There's a TODO in the embedded test (739). I notice what looks like setting SOLR_URL as an environment variable, can we do something similar for SOLR_HOME? I've also uploaded a new patch for 738 that should be in the right package. But that's really an aside. I guess I'm not sure how far to take creating tests. At this point we've hit a bunch of major units of Solr, although extremely shallowly. My personal feeling is that we should just get this in place then expanding them as needed. The tests so far are a bit fragile, just something to keep in mind. They use the example installation and manipulate the index there, attempting to clean things up tidily. All well and good, but that makes the state of the index files suspect with more extensive tests. The regular Solr tests have a complicated way of creating temp directories to bypass this problem, but again I think that's for "the future", if we find we need more robustness in the tests. My personal feeling is that we're testing "if everything goes right" here, not "can we handle all the strange cases that could exist". So lets add the two JIRAs (738 and 739) and I'll close all that series. Thanks so much for doing the hard parts!
        Hide
        Roman Shaposhnik added a comment -

        I pooled all the available tests from the subjiras into this patch.

        Erick, please take a look and let us know whether you'd want to provide more tests on BIGTOP-737, BIGTOP-738, BIGTOP-739 following the template that I'm attaching. If you think we've got an adequate # of simple smoke tests – feel free to close those 3 jiras.

        Show
        Roman Shaposhnik added a comment - I pooled all the available tests from the subjiras into this patch. Erick, please take a look and let us know whether you'd want to provide more tests on BIGTOP-737 , BIGTOP-738 , BIGTOP-739 following the template that I'm attaching. If you think we've got an adequate # of simple smoke tests – feel free to close those 3 jiras.
        Hide
        Erick Erickson added a comment -

        I built and installed Solr from Bigtop after applying the patch (BIGTOP-723) in an Ubuntu VM (VirtualBox). The attached SimpleTest.groovy script that ran just fine. I verified that assertions happen (try the -x option).

        There's also a -v option to see some output as tests go by.

        I admit I'm surprised that I didn't have do to things like set the classpath. Is this BigTop magic? Or does the test really need to be written in pure Java? Let me know if I need to make it run in Java.

        So, after talking with Roman, I think I'm done here until this gets worked into iTest etc. These tests are completely and utterly trivial, and this one in particular is hacked up just to run outside of junit as a simple groovy script. It's no more than a place to start, I expect that we'll totally replace it once it gets a home in the "real" system.

        Show
        Erick Erickson added a comment - I built and installed Solr from Bigtop after applying the patch ( BIGTOP-723 ) in an Ubuntu VM (VirtualBox). The attached SimpleTest.groovy script that ran just fine. I verified that assertions happen (try the -x option). There's also a -v option to see some output as tests go by. I admit I'm surprised that I didn't have do to things like set the classpath. Is this BigTop magic? Or does the test really need to be written in pure Java? Let me know if I need to make it run in Java. So, after talking with Roman, I think I'm done here until this gets worked into iTest etc. These tests are completely and utterly trivial, and this one in particular is hacked up just to run outside of junit as a simple groovy script. It's no more than a place to start, I expect that we'll totally replace it once it gets a home in the "real" system.
        Hide
        Erick Erickson added a comment -

        Tests for the record, at least a place to start.

        Show
        Erick Erickson added a comment - Tests for the record, at least a place to start.

          People

          • Assignee:
            Roman Shaposhnik
            Reporter:
            Erick Erickson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development