I want to introduce the concept of unit tests (and testing in general) to my co-workers; right now there are no tests at all and things are tested by actually performing the tasks via the UI to see the desired result. As you might imagine, the code is very tightly coupled to the exact implementation - even resulting in code that should be in a class and reused across the system being copied and pasted across methods.
Due to changed requirements, I have been asked to modify a module I previously wrote and that is fairly loosely coupled (not as much as I would like, but as best I can get without having to introduce a lot of other concepts). I've decided to include a suite of unit tests with my revised code to "prove" that it works as expected and demonstrate how testing works; I'm not following true TDD as some of the code is already written but I'm hoping to follow some TDD concepts for the new code I'll have to create.
Now, inevitably I'm sure I'll be asked why it's taking me more than a day or two to write the code, since parts of what I'll be interacting with already exist in the system (albeit without any tests and very tightly coupled), and when I check the code in I'll be asked just what this "Tests" project is. I can explain the basics of testing, but I can't explain the actual benefits in a way the others would understand (because they think testing requires you to run the app yourself, since often the actual UI matters in determining if the feature "works" or not). They don't understand the idea of loose coupling (clearly evident by the fact nothing is loosely coupled; there aren't even any interfaces outside of the code I've written), so trying to use that as a benefit would probably earn me a "Huh?" kind of look, and again I can't be as loose as I would like to without having to rework several existing modules and probably introduce some kind of IoC container, which would be viewed as wasting time and not "programming".
Does anyone have any suggestions on how I can point to this code and say "We should start creating unit tests" without coming off as either condescending (e.g. "Writing tests forces you to write good code." which would probably be taken to mean code except mine is bad) or without making it seem like a waste of time that doesn't add any real value?