I believe that will only work for DHCP connections. I don't think statically mapped IPs don't respond to that.
On the underlying testing issue: it seems to me that the cure is worse than the disease. Frobbing the local machine's network settings in order to simulate loosing a connection to a server seems heavy-handed. Much more so than closing the connection object (perhaps through a test helper function).
For cases like this I typically use Cisco switches and write a script to disable the port which is equivalent to disconnecting the cable.
First of all, DRY! These two functions are almost carbon copies of each other. It would read a lot more nicely if you could ipconfig("release") and ipconfig("renew").
Second, full functional integration tests are great for polish, but do you have unit test coverage for this? Closing the relevant connection object inside the guts of the application might be a nasty, encapsulation-breaking way to test this but surely there's something nicer you can do without failure-prone interaction with the OS; say, a connection *manager* object that you could provide a mock implementation of which would close _all_ its connections, simulating an actual network shutdown? Or, perhaps, simulating intermittent network access?
Third, as others have noticed, this isn't a reliable way to "unplug" the cable on Windows. Renew and release are DHCP lease commands, and quite often TCP connections will stay open past the lease lifetime (depends on your router, etc.)
> First of all, DRY!
Fully agree.
> Second, full functional integration tests
> are great for polish, but do you
> have unit test coverage for this?
We start with Functional Test that follows a user story. Only when we finish simulating the main use case we go to unit tests where we try to fully cover all cases.
As you said, mocking connections in Connection Manager is the way to go on the unit test level.
> Third, as others have noticed,
> this isn't a reliable way to
> "unplug" the cable on Windows.
Yes, it might be a problem when we change the network setup. However, our tests should show the problem very quickly. Any suggestions how can we better simulate unplugging a cable?
Pulling a cable is quite difficult to simulate.
In cases where it's important (and it'll really depend on what your functional test is trying to prove), downing the interface will give an instant RST on the socket, whereas pulling the cable will leave you waiting for a timeout (upwards of 10 minutes for some TCP stacks).
Of course, different operating systems behave differently too. Perhaps you only care about Windows, but if Mono on Linux/Solaris/OSX is relevant, using ipconfig certainly won't work 
If you care about these differences, talking to the switch might be the best approach.
David -- I'm not certain, but I believe that, under Windows, pulling the cable is detected by the network stack (actually, the Media Presence Detect system), which responds immediately by downing (disabling) the interface. So you do get a RST on the socket right away (within a second or two).
I agree that the "proper" solution is either farther in or farther out than the proposed solution. Farther in is a connection abstraction class that includes "disconnect" functionality, farther out is contacting the upstream switch to disable the port.
If you're wedded to the OS-level operation, you might consider using a system call to actually disable the network device directly. It'll require more scaffolding, but it will work with all network configurations, and should more accurately simulate what the Media Presence Detect system will do on a cable disconnect.
Commenting by HaloScan
