I am on vacation, and it is awesome... but since I have a few minutes...
With the unit tests, you'd be saying "I want to make sure these things won't be an issue."
If you did your testing properly before hand, there is no reason to deploy the tests.
You can't guarantee that the client machine is going to behave like your test machine(s). It isn't a perfect solution, but it gives you the assurance that at least your unit tests work on the client machine. Have a good vacation!
Speed of the network or database is not my problem. DLL hell hasn't been a real problem in such a long time, that point is moot. You can't unit test for stupidity. You should be controlling the release processes anyway. Especially internally. How do you unit test for the correct database version anyway?
You can't test for stupidity, but that doesn't mean stupidity won't waste your time! You see quite a few issues with DLL hell on govt job sites, but it doesn't have to be external libraries -- You want to ensure that the client is using the correct version of your library, right?
From what I've seen, most databases still include the equivalent of a 'database -v', so you could check the version that way or by using internal system tables. What I really meant is to test for the correct schema version. Many defense companies 'deliver databases' which can become a sort of data DLL hell. Generally, in this case, you would check that the schema information version stored in the database is correct. If you were paranoid, you might also include checks to make sure the schema was as you expect (check for tables, then fields, then data types using the system tables).
Here is the main issue I have with unit testing... how do you unit test the unit tests? I know it is supposed to be a small enough unit to be easily verifiable...but it still seems a little like writing code to test code. You can still have issue? How common is it to have issue with unit tests?
Generally, if you're having trouble writing a unit test for a piece of code, there is a very high probability that the code in question is badly written. It needs to be refactored. I've never really had issues with unit tests, but I tend to write most of my code in a functional style, so I have small(ish) well-defined functions that are easily tested.
Regarding issues with unit test code...
true negative - The code is correct; The unit tests pass.
false negative - The unit tests pass, but the code isn't correct. You haven't done sufficient testing.
true positive - Here the unit tests fails on a piece of code with an error. Make sure that you don't have a false positive, then fix the code.
false positive - Usually this is easiest to correct (simply rewrite the unit test), but it might bring up some concern about your design (eg should I return null or an empty list).
IMHO, unit tests are invaluable. Sure, you can't test a UI very well with them, but you can find/fix many errors with them.
I am sure there are lots of above average companies with large, difficult to maintain code bases. It is hard to justify going back and spending extra time to fix things and add proper unit tests because it doesn't provide any forward velocity.
What are the options? To not fix things? To not be proactive?
Well good on you that you have been able to get the time. I have never been able to get the time to fix it properly and set it up to avoid issue in the future. The emphasis is always on getting things done even if they are less that correct.
Oh, don't get me wrong. I've also been bombarded with the "please figure out a quick fix" to someones craptastic software. I hate having to play the office politics games, but I'll play if that is what it takes...
"Uh, it'll take me longer to familiarize myself with the software than for the person who originally wrote it to fix it, so why don't you just have them fix it. From what I've seen, I can't believe this xxx works at all."
"If there was a quick fix, why hasn't someone already done this?"
"What do you mean that you don't actually want me to 'really fix' the software? You want me to leave it broken?"
etc. I actually hate playing games, but some places force it. Usually errors are clustered within software, so you can probably find enough additional errors to justify a proper fix.
Of course, you should probably be asking yourself the following question: why am I working for a company that won't allocate me enough time to properly fix their software? After all, you can't expect to get rich working for a companies that cannot afford to fix their software (w/ the exception of a few companies with monopoly power). Find a better job or ask for a transfer or something.