GeoServer

add some kml tests

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.7.0-RC3
  • Fix Version/s: 1.7.0-RC4
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    2

Description

Currently we have zero kml tests. And there is really no part of the manuall hand testing of a release which tests it either. This has caused a number of regressions with regard to KML on 1.7.x.

We need to implement at least a few tests for 1.7.x It does not have to be comprehensive coverage at this point... just a way to ensure that things are not completely broken.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Gabriel Roldán added a comment -

The two attached pictures show the kml package coverage before and after the tests added by Dave and me.
Note however, that though we had a 51% coverage it was mostly due to ghost tests. We added a lot of assertions over the generated document structure on those tests too so we're actually asserting the class in questions produces the expected output. So even if the coverage raised from 51% to 80%, some existing tests that were performing just naive assertions now are checking a lot more, even if that doesn't repercutes in more coverage

Show
Gabriel Roldán added a comment - The two attached pictures show the kml package coverage before and after the tests added by Dave and me. Note however, that though we had a 51% coverage it was mostly due to ghost tests. We added a lot of assertions over the generated document structure on those tests too so we're actually asserting the class in questions produces the expected output. So even if the coverage raised from 51% to 80%, some existing tests that were performing just naive assertions now are checking a lot more, even if that doesn't repercutes in more coverage
Hide
Permalink
Gabriel Roldán added a comment -

btw, as for the new test classes I've added, I'm on this situation:

  • the wms module builds fine on my box, but somehow they lead to another, unrelated tests to fail in hudson:
    Failed tests:
    testRasterPlacemark(org.vfny.geoserver.wms.responses.map.kml.KMLTransformerTest)
    testReproject(org.vfny.geoserver.wms.responses.map.georss.RSSGeoRSSTransformerTest)
    test2(org.geoserver.wms.DefaultWebMapServiceTest)
    test3(org.geoserver.wms.DefaultWebMapServiceTest)
Show
Gabriel Roldán added a comment - btw, as for the new test classes I've added, I'm on this situation:
  • the wms module builds fine on my box, but somehow they lead to another, unrelated tests to fail in hudson: Failed tests: testRasterPlacemark(org.vfny.geoserver.wms.responses.map.kml.KMLTransformerTest) testReproject(org.vfny.geoserver.wms.responses.map.georss.RSSGeoRSSTransformerTest) test2(org.geoserver.wms.DefaultWebMapServiceTest) test3(org.geoserver.wms.DefaultWebMapServiceTest)
Hide
Permalink
David Winslow added a comment -

And I see yet other tests that also fail. In the particular case I'm looking at, I see
testNoBBOXInHREF(org.vfny.geoserver.wms.responses.map.kml.KMLReflectorTest) Time elapsed: 0.042 sec <<< FAILURE!
junit.framework.ComparisonFailure: expected:<...st:80/geoserver/wms?[format_options=KMPLACEMARK%3Afalse%3BKMATTR%3Atrue%3BKMSCORE%3A50%3B&service=wms&srs=EPSG%3A4326&width=1024&styles=BasicPolygons&height=1024&transparent=false&request=GetMap&layers=cite%3ABasicPolygons&format=application%2Fvnd.google-earth.kmz%2Bxml]&version=1.1.1> but was:<...st:80/geoserver/wms?[height=1024&width=1024&layers=cite%3ABasicPolygons&request=GetMap&service=wms&styles=BasicPolygons&format_options=KMPLACEMARK%3Afalse%3BKMSCORE%3A50%3BKMATTR%3Atrue%3B&srs=EPSG%3A4326&format=application%2Fvnd.google-earth.kmz%2Bxml&transparent=false]&version=1.1.1>

I think what's going on is that we are specifying the exact query string when really the parameter map is what we care about, so when I run the test in Java 6 the parameters come out in a different order than when you run it in Java 5. I'll dig a bit to see what's going on here.

Show
David Winslow added a comment - And I see yet other tests that also fail. In the particular case I'm looking at, I see testNoBBOXInHREF(org.vfny.geoserver.wms.responses.map.kml.KMLReflectorTest) Time elapsed: 0.042 sec <<< FAILURE! junit.framework.ComparisonFailure: expected:<...st:80/geoserver/wms?[format_options=KMPLACEMARK%3Afalse%3BKMATTR%3Atrue%3BKMSCORE%3A50%3B&service=wms&srs=EPSG%3A4326&width=1024&styles=BasicPolygons&height=1024&transparent=false&request=GetMap&layers=cite%3ABasicPolygons&format=application%2Fvnd.google-earth.kmz%2Bxml]&version=1.1.1> but was:<...st:80/geoserver/wms?[height=1024&width=1024&layers=cite%3ABasicPolygons&request=GetMap&service=wms&styles=BasicPolygons&format_options=KMPLACEMARK%3Afalse%3BKMSCORE%3A50%3BKMATTR%3Atrue%3B&srs=EPSG%3A4326&format=application%2Fvnd.google-earth.kmz%2Bxml&transparent=false]&version=1.1.1> I think what's going on is that we are specifying the exact query string when really the parameter map is what we care about, so when I run the test in Java 6 the parameters come out in a different order than when you run it in Java 5. I'll dig a bit to see what's going on here.
Hide
Permalink
Andrea Aime added a comment -

Mass close all issues that have been resolved for more than one month without further comments (assuming they are fixed for good since there is no more discussion)

Show
Andrea Aime added a comment - Mass close all issues that have been resolved for more than one month without further comments (assuming they are fixed for good since there is no more discussion)

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.