Bug #3367
closed
IPv6 test cases should be skipped if IPv6 is not available
Added by Alex Afanasyev almost 9 years ago.
Updated over 8 years ago.
Description
Travis-CI does not have any support for IPv6... not even on loopback interfaces.
This results in several failures in test cases, e.g. from https://travis-ci.org/named-data/NFD/builds/105011116
Entering test suite "TestTcpTransport"
Entering test case "StaticPropertiesLocalIpv4"
1453846242.616016 INFO: [TcpTransport] [id=0,local=tcp4://127.0.0.1:33324,remote=tcp4://127.0.0.1:7070] Creating transport
Leaving test case "StaticPropertiesLocalIpv4"
Entering test case "StaticPropertiesLocalIpv6"
unknown location(0): fatal error in "StaticPropertiesLocalIpv6": std::runtime_error: bind: Cannot assign requested address
Leaving test case "StaticPropertiesLocalIpv6"
... ...
Entering test suite "TestUnicastUdpTransport"
Entering test case "StaticPropertiesLocalIpv4"
1453846242.621958 INFO: [UnicastUdpTransport] [id=0,local=udp4://127.0.0.1:36982,remote=udp4://127.0.0.1:7070] Creating transport
Leaving test case "StaticPropertiesLocalIpv4"
Entering test case "StaticPropertiesLocalIpv6"
unknown location(0): fatal error in "StaticPropertiesLocalIpv6": std::runtime_error: connect: Network is unreachable
Leaving test case "StaticPropertiesLocalIpv6"
We should add guards to skip the affected tests when IPv6 is not available at all.
- Tracker changed from Task to Bug
- Description updated (diff)
- Target version changed from v0.4 to v0.5
- Start date deleted (
12/21/2015)
The "NonLocalIp" tests already have guards in v0.4.0. We need to add similar guards to the "LocalIp" test cases.
- Status changed from New to Code review
- Assignee set to Davide Pesavento
- % Done changed from 0 to 50
Snippet from NFD:commit:ba9e4a4097726ea15a43d6acd7dc89e6664f8723 :
template<typename A>
A
getAvailableInterfaceIp(bool wantLoopback = false, bool needMulticast = false);
I'm not particularly happy with the two boolean arguments of getAvailableInterfaceIp()... they're not very self-descriptive at the call sites.
One solution is:
enum AvailableInterfaceFlags {
AVAILABLE_INTERFACE_NONE = 0,
AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
AVAILABLE_INTERFACE_MCAST = (1 << 1)
};
template<typename A>
A
getAvailableInterfaceIp(AvailableInterfaceFlags flags);
Junxiao Shi wrote:
One solution is:
enum AvailableInterfaceFlags {
AVAILABLE_INTERFACE_NONE = 0,
AVAILABLE_INTERFACE_LOOPBACK = (1 << 0),
AVAILABLE_INTERFACE_MCAST = (1 << 1)
};
Is this powerful enough though? I think we actually need 3 states for each network interface trait:
- yes, the trait must be present
- no, the trait must not be present
- don't care, the trait can be present or not, it doesn't matter
Reply to note-4:
It's as powerful as two booleans.
The complaint quoted in note-3 is about code readability, not about flexibility.
Absolutely. But since we're talking about the API, I wanted to go one step further and make it more flexible.
Also note that the two booleans in the current patch are named differently because they have different semantics when their values are set to false.
flexibility == complexity
Current use cases do not need flexibility, but only need readability.
- % Done changed from 50 to 60
I've experimented with Boost.Parameter library but I gave up because it doesn't seem to be usable with function templates and specializations.
http://gerrit.named-data.net/2779 PS3 proposes a more self-descriptive API based on enumerators (see test-ip.hpp).
- % Done changed from 60 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by