When looking at something that's going to prove nasty to test, you can apply the same criteria as Holmes: Once we remove the untestable, what remains, however difficult, must be testable.
What's the problem with testing libnet? The network connection. We can't guarantee that the machine will have the ability to produce net connections at all, whether local or remote. Ok. The second part to analyzing a nasty test case is to winnow away the unimportant bits. Parts of the process that either are incidental, or are well-tested elsewhere. Let's take something like Net::Time. What does Net::Time do? It queries servers, using a simple (but specific) protocol, to find the time of day. What's the most important part there? That you understand the protocol and get the time of day. The fact that this is done over a network is largely incidental. It's uninteresting. It's a solved problem. Let's take another, Net::FTP. It's a File Transfer Protocol. It speaks a specific set of queries and responses to send and receive files over sockets. The fact that it does this over a real network connection is not where the complexity lies. The difficult part is speaking FTP. The fact that you speak it over a network socket, a dummy object or on paper is incidental. Essentially, it's more important that it's "FTP" than that it's "Net". The libnet modules implement a series of protocols that are best used over a network but it's *not essential* that they actually travel over a network. In contrast, IO::Socket::INET is the other way around. In that case, the fact that it speaks over the Internet is central to it's purpose. For libnet it happens to work out that the untestable part (the network connection) is incidental. The testable part (the protocol) is essential. That's the sweet spot. If we can seperate the net connection from the protocol, we've got it made. No need for elaborate skip tests and assumptions about platforms. chromatic did just that. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-10/msg00837.html Employing the 7-layer burrito model of networking protocols [1], chromatic has simply pulled a switcheroo with Mock::Socket at a layer below that which libnet cares about. So Net::FTP thinks it's talking to an FTP server, when in reality it's connection has been hijacked and a dummy test server put in it's place. So we can exercise the FTP protocol without having to worry about the details of making a network connection. The essential, testable bits can be tested. The incidental, untestable bits are avoided. So we can test libnet. We can do it on all platforms. We don't have to muck about with any more $^O hackery than usual. Most tests will involve writing some sort of dummy server. For some, this will be easy (Net::Ping, Net::Time) for others it might be hard (Net::FTP), but it's possible. [1] http://www.randywanker.com/OSI/ I think I just wanted to mention the network burrito. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One "None of our men are "experts."... because no one ever considers himself expert if he really knows his job." -- From Henry Ford Sr., "My Life and Work," p. 86 (1922):
