You could make the called function mockable
int (*ptr_getaddrinfo)(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
ptr_getaddrinfo = &getaddrinfo
void mock_it(... new_ptr) {
ptr_getaddrinfo = new_ptr;
}
so that when testing you're not calling the system one. It's a fairly
standard mocking technique, it just gets bit ugly in C because it's
not a dynamic language - you have to replace all your calls to
getaddrinfo with calls to ptr_getaddrinfo - maybe there's some jiggery
pokery you could do to avoid that, I'm not sure.
The other alternative it to create a small library with a mock
getaddrinfo function in it and when compiling the tests, make sure it
gets linked in ahead of the libc but I fear that doing that in a
cross-platform way while maintaining your sanity may be tricky,
F
On 29/01/2008, Paul LeoNerd Evans <[EMAIL PROTECTED]> wrote:
> I'm finding it difficult to come up with a good testing strategy for an
> XS module that's just a thin wrapper around an OS call, without
> effectively also testing that function itself. Since its behaviour has
> minor variations from system to system, writing a test script that can
> cope is getting hard.
>
> The code is the 0.08 developer releases of Socket::GetAddrInfo; see
>
> http://search.cpan.org/~pevans/Socket-GetAddrInfo-0.08_5/
>
> for latest.
>
> The code itself seems to be behaving on most platforms; most of the test
> failures come from such things as different OSes behaving differently if
> asked to resolve a host called "something.invalid", or quite whether any
> system knows the "ftp" service, or what happens if it wants to reverse
> resolve unnamed 1918 addresses (e.g. 192.168.2.2).
>
> The smoke testers page is showing a number of FAILs on most platforms not
> Linux (where I develop), probably because of assumptions the tests make
> that don't hold there any more. E.g. one problem I had was BSD4.4-based
> systems, whose struct sockaddr_in includes the sin_len field.
>
> http://cpantesters.perl.org/show/Socket-GetAddrInfo.html
>
> Does anyone have any strategy suggestions for this?
>
> --
> Paul "LeoNerd" Evans
>
> [EMAIL PROTECTED]
> ICQ# 4135350 | Registered Linux# 179460
> http://www.leonerd.org.uk/
>
>
