Frustrations: Testing networked code

I hate testing network related code. Mostly because there is far too many moving parts in it.
For example you can't really unittest the actual socket itself. Because what happens if something wonky happens with the network stack? Or a process dies suddenly. How do you handle that? You can't really.

There is simply too many moving parts to make it work well. This is why frameworks like GUI toolkits and web sites are not properly tested. Because its so difficult.

This is why I'm questioning how we as developers setup the entire ecosystem to mean that we can't actually test things properly. We have been so focused upon getting stuff done then actually make everything work together nicely.
Furthermore I believe having multiple languages with no language being the language to work with as default has hurt this. In some ways C has taken this up and a little bit C++ but nothing really cross platform wise in this regard.

Furthermore libraries that do 'mocking' of objects are an amazing way to test code bases. In terms of networking this would be perfect to be able to say, you receive x then you should send y. Sure its possible to abstract it out and have your own special testable library but this is really absurd to have to do.

The way we have done things seems so unproductive its ridiculous. Yet we try to be as productive as possible.

So if anything these annoyances have taught me something. If I were to write my own language and OS I will do these things:

• All code must be testable
  If that means designing standard library around this first, then it will be so. If at worse the language itself will have more than just 'unittest' support by default.
• System shell as part of the language. Using the system shell should be directly accessible from the language. It shouldn't require calling functions. It should be implicit. In fact the system shell should be a library.
• Isolate processes, being able to isolate processes when ran will provide everything from sandboxing of untrusted code to custom it can see x parts of the system.
• Dynamic calling of libraries by the shell. 
• Don't cheap out of libraries. If a library is required to do X  for regularly or common use, include it by default with the system.
• Every application is a library. But each library can have 'routed' main functions.
• Applications are merely plugins to the OS to make it do stuff. At which they can be enabled/disabled at boot. Should anything go wrong. However they are not kernel extensions.
• Everything must be scriptable. For pretty much anything. If you can do it via manual input (keyboard/mouse) it can be done by a script/code easily.
• Version control, version everything. Take versioning and snapshots to the extreme. It should be easy to do and required.
• CTFE is amazing do it (include a JIT for that), hint shell.
• Modularity is key. Don't want something? don't use it.
• Automation. If it can be automated while being flexible and simple for regularly use do it.

But these are just some ideas that would help. I just so wish others felt the same way as me so that it could be actually done.