bug #2495
open
IpniServiceTest fails from time to time
Added by Andreas Kohlbecker almost 13 years ago.
Updated about 5 years ago.
Description
eu.etaxonomy.cdm.ext.ipni.IpniServiceTest.testPublications
java.lang.NullPointerException
at eu.etaxonomy.cdm.ext.ipni.IpniServiceTest.testPublications(IpniServiceTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
- Target version set to cdmlib RELEASE 3.0.7
- Target version deleted (
cdmlib RELEASE 3.0.7)
- Priority changed from Priority08 to Highest
- Description updated (diff)
- Status changed from New to Closed
- Assignee changed from Andreas Müller to Andreas Kohlbecker
- Target version changed from cdmlib - Old Next Major Release to Release 4.6
fixed by 9a211f9
this is actually very quick and easy to achieve:
@Before
public void setUp() throws Exception {
// run the tests only when the server is available
Assume.assumeTrue(UriUtils.isServiceAvailable(new URI("http://www.uk.ipni.org/ipni/simplePlantNameSearch.do?find_wholeName=Abies+albertiana&output_format=delimited-short"), 1000));
// prepare tests
service1 = new IpniService();
}
The test are all successful if the server is absent!
- Status changed from Closed to Feedback
Andreas Kohlbecker wrote:
fixed by 9a211f9
this is actually very quick and easy to achieve:
The test are all successful if the server is absent!
But this is only one part of the tasks that need to be done.
Second step: Create a test that fails when and only when the service is unavailable. This test must not be included in the cdmlib maven test but run separately in jenkins.
If we do not have this test we can not see if a service is permanently down or has changed its URL syntax/location, but this is crucial to guarantee that the external services work.
Also we should implement this for ALL external service tests.
- Status changed from Feedback to Closed
- Private changed from Yes to No
Andreas Müller wrote:
Andreas Kohlbecker wrote:
fixed by 9a211f9
this is actually very quick and easy to achieve:
The test are all successful if the server is absent!
But this is only one part of the tasks that need to be done.
Second step: Create a test that fails when and only when the service is unavailable. This test must not be included in the cdmlib maven test but run separately in jenkins.
If we do not have this test we can not see if a service is permanently down or has changed its URL syntax/location, but this is crucial to guarantee that the external services work.
Also we should implement this for ALL external service tests.
This is a good suggestion. However, we should not implement these tests as part of the cdm library for the following reasons:
- Sooner or later you will be faced with the task to do more in depth testing than only to check for HTTP Status codes. You would be starting to implement a couple of helper methods in this situation which grow after a while towards a little framework. But, It makes not much sense to reinvent the wheel of a web service testing framework. There are excellent tools out there, For example Gatling.
- Having these tests in a separate project will reduce the confusion, since these tests could be run automatically by the default way. Otherwise you need a naming convention for these tests to run them in a separate suite.
- The cdmlib is not the only project which depends on external services. Testing external services is a more general taks for the BDI and also for external projects.
Please open a new ticket, since this one is completed. The subject and issue description do not mention this second step by the way!
- Status changed from Closed to Feedback
Andreas Kohlbecker wrote:
Andreas Müller wrote:
Andreas Kohlbecker wrote:
This is a good suggestion. However, we should not implement these tests as part of the cdm library for the following reasons:
- Sooner or later you will be faced with the task to do more in depth testing than only to check for HTTP Status codes. You would be starting to implement a couple of helper methods in this situation which grow after a while towards a little framework. But, It makes not much sense to reinvent the wheel of a web service testing framework. There are excellent tools out there, For example Gatling.
- Having these tests in a separate project will reduce the confusion, since these tests could be run automatically by the default way. Otherwise you need a naming convention for these tests to run them in a separate suite.
- The cdmlib is not the only project which depends on external services. Testing external services is a more general taks for the BDI and also for external projects.
Please open a new ticket, since this one is completed. The subject and issue description do not mention this second step by the way!
I did not say that we should integrate these tests into cdmlib. But they need to be in place before we can switch off availability testing within cdmlib. Until then we have to revert this ticket, therefore reopened it.
- Blocked by bug #6415: Create test suite for availability testing of external services added
- Assignee changed from Andreas Kohlbecker to Andreas Müller
I applied this fix because I was blocked by the IPNI Service not being available for quite some time. The cdmlib could not be build and the whole build pipeline was blocked due to this. This Problem also can break any release. I don't agree with you in this, but I reverted the fix as you requested and will no longer work in this ticket, it's your turn!
- Target version changed from Release 4.6 to Release 4.7
- Target version changed from Release 4.7 to Release 4.8
- Target version changed from Release 4.8 to Release 4.9
- Target version changed from Release 4.9 to Release 4.10
- Target version changed from Release 4.10 to Release 4.11
- Target version changed from Release 4.11 to Release 4.12
- Target version changed from Release 4.12 to Release 4.13
- Target version changed from Release 4.13 to Release 4.14
- Target version changed from Release 4.14 to Release 5.0
- Target version changed from Release 5.0 to Release 5.1
- Target version changed from Release 5.1 to Release 5.3
- Target version changed from Release 5.3 to Release 5.4
- Target version changed from Release 5.4 to Release 5.5
- Target version changed from Release 5.5 to Release 5.6
- Target version changed from Release 5.6 to Release 5.7
- Target version changed from Release 5.7 to Reviewed Next Major Release
Also available in: Atom
PDF