Maybe you can help me understand something because I hear this a lot. You manually debug and run your code through "the happy path and edge cases", if I'm under

Maybe you can help me understand something because I hear this a lot. You manually debug and run your code through "the happy path and edge cases", if I'm understanding you correctly... so, does it really take that much longer to write an automated test that does the same thing? What I'm saying is if we accept the company's viewpoint as truth -- I don't -- then you'd just be writing code and handing it over. No testing. No execution. No nothing. But if you have time to manually test the code, then it sounds like you have time to write automated tests. Now, I'm with you, these tests aren't going to be beautiful or well-factored, but they'll be helpful to you, right? That way you don't have to manually test the code over and over again. On the other side of the coin, I've taken on the practice of including time necessary for testing in my estimates (as an employee and contractor). If a manager doesn't want to accept that, then they can fire me, because that manager is fully incompetent -- no ifs ands or buts. As a professional, I need to operate with a test-driven approach. It's the only way to deliver complex systems with confidence. Testing happens one way or another.