0

I am writing a test unit for function named pkg_getclient (). It is, basically, a function that listens indefinetly for a client.
Here is the implementation : http://slexy.org/view/s21RBuOUOu (pasted there to keep question text size reasonable )

Here is an example of a client - server test : http://slexy.org/view/s2fS5hBkgI

This is the current status of my unit test :

int test_pkg_getclient (char* portname) {
int netfd;
struct pkg_conn *result;
netfd = pkg_permserver(portname, "tcp", 0, 0);

/* validate_port(port); */
printf("TESTING PKG_GETCLIENT...\n");

result = pkg_getclient(netfd,callbacks, NULL, 0);

printf("TESTING VALID FILE DESCRIPTOR\n");
if (result  == PKC_ERROR)  {printf ("\t[ FAILED ]\n");
} else  { printf ("\t[ PASSED ]\n");
}
return 0;
}

int main (int argc, char* argv[]) {
test_pkg_getclient(argv[1]);
printf("%d",argc);
return 0;
}

I need to break the pkg_getclient() blocking call. It needs to be portable to Windows aswell, not only unix-based systems. I cannot modify the pkg_getclient() function. The blocking function is inside getclient().

Is there any way to use signal handling to break the blocking call? Or is there any other way around this ?

pAndrei
  • 383
  • 6
  • 19

2 Answers2

1

Honestly, I don't think this really qualifies as unit test since you also involve the whole networking stack.

I would suggest a different testing strategy: change your code so that it allows Dependency Injection. That is, it should be possible to pass a reference at run-time to the network stack to use. For production code, you would use the real one of course, but for unit testing purpose, you use a mock stack that implements the minimal behavior needed to cover what you want to test.

If you want to have your tests to stretch also onto the real networking stack (in which case to me we deal with integration rather than unit test) I personally find it simpler to create little programs and have them glued together via higher level scripts (bash, python, etc).

SquareRootOfTwentyThree
  • 7,606
  • 32
  • 43
0

First of all you may want to call fork(2) before calling pkg_getclient (assuming pkg_getclient is blocking). Secondly I just wouldn't use blocking calls, instead I'd use either non-blocking sockets or select(2).

As for portability, fork() and pthreads are portable across most unices. As for Windows, there are implementations of pthreads for it but only emulation of fork() (e.g. Cygwin implements this).

Giel
  • 2,787
  • 2
  • 20
  • 25
  • I can't / shouldn't change the structure of what I am testing so I can't use non-blocking sockets. I will probably take a look at select – pAndrei Jul 25 '12 at 08:45
  • still haven't found the solution to break out of a blocking call – pAndrei Aug 03 '12 at 09:04
  • @pAndrei: The best you can do is set a timeout with alarm(2) and install a signal handler for SIGALRM. That will (when the the timer triggers) call the signal handler, interrupting the blocking syscall. This will allow your test-code to gain control again, that's a strategy that's likely only usable to make your unittest fail on exceeding a time-limit (although as SquareRootOfTwentyThree says this is slightly too large to be called a unittest.) – Giel Aug 03 '12 at 20:38