commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: svn commit: r1535297 - in /commons/proper/configuration/branches/RELEASE_1_10_BRANCH: NOTICE.txt build.xml pom.xml src/site/resources/profile.cobertura src/test/java/org/apache/commons/configuration/
Date Fri, 25 Oct 2013 13:42:00 GMT
On 25 October 2013 06:51, Thomas Neidhart <> wrote:
> On 10/25/2013 01:35 AM, sebb wrote:
>> On 24 October 2013 08:53,  <> wrote:


>>> @@ -1711,7 +1711,7 @@ public class TestDataConfiguration
>>>      @Test(expected = ConversionException.class)
>>>      public void testGetInetAddressInvalidType()
>>>      {
>>> -        conf.setProperty("ip.unknownhost", "foo");
>>> +        conf.setProperty("ip.unknownhost", "random-foo-that-does-not-exist.ever");
>> That's not guaranteed to never exist.
>> However, the TLD "invalid" is specifically designed for such a purpose.
>> i.e. use conf.setProperty("ip.unknownhost", "foo.invalid");
> I would not rely on that in every environment.
> For commons-email we had certain tests fail because some providers still
> resolved this name to something.

It's true that OpenDNS used to resolve this to their web server (as
for any other non-existent domain).
However, they have now finally fixed the behaviour to be RFC-compliant.

I still think it's better to use the correct TLD for testing
That may possibly cause the test to fail with some misbehaving DNS
providers, but won't fail everywhere.
Whereas if the random host name is ever defined, it will fail everywhere.

> So if you have a test that relies on an exception if you want to open a
> stream to the invalid host better mock that behavior in your test.

That may be another approach, depending on what is being tested.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message