That is a little sad. Do they get upset when there are bugs in production code? I don't revisit the question often because I have accepted wholeheartedly that I must unit test any code I offer to another person, whether that be through an application at an engagement where I am being compensated with dollars or even on an online forum where I am offering free help or advice. I haven't met anyone in this business that categorically objects to unit testing code before it is shipped. Noone managing code delivery projects is fit for that role if they think unit testing is generally a waste of time.

Note that I am parsing the automating of unit testing out of that discussion however. Many managers simply won't pay for the effort to structure the unit tests so they can be run unattended and then maintain those tests as an integral part of the codebase and I get that part of the objection. It has a real cost. That said, those same managers often still expect bugs to be rare and code regressions to be non-existent.

If you start with the premise that unit testing is necessary before offering any warranty on your code, whether implied or explict, which I do, then why not use a tool to make those tests easier to write and reuse later? Seems silly to argue the converse at this point with the free, very robust tools we have at our disposal.

The MS Unit Test Framework was implemented in .NET but you don't need to know a lick of C# to write or run T-SQL Unit Tests. All unit tests are written 100% in T-SQL. The farthest away from T-SQL it might take you is when editing an XML config file to set the connection strings so the tests can reach your database. I work in MS Unit Test Projects all the time and it helps me write better code.