Quote:
Originally Posted by Biggle10
The part I'm struggling with mentally is the time to do it. I've read plenty where people say once you're used to it it doesn't add that much more time to your DEV process and saves time in the long run. But for example, management/product owner says how long will it take to do feature x. I say a week as I am including some time to write tests, etc. Management says is there anyway to make that faster as customer really needs that feature right now and a week seems too long. Since I'm new to unit testing stuff, I could do it faster if I ignored it but I'm not sure how to answer that question then to management.
As an aside, that particular manager is no longer here and the way we do estimation is different now, but I'm reflecting back on how I could've/should've done things differently.
Probably the type of management you are describing doesn't care about unit testing.
I've been there, and it is tough, but how you address that, it depends.
You just say your time, don't say it takes my five days, but without test, it takes me two.
First, you decide if you do test or not. Ideally, you should always do unit testing, but there are some factors that maybe you shouldn't do it.
Maybe it is a legacy product, and if you do unit tests, it will take you forever.
Unit testing is a trade-off between cost now and benefits later.
But the thing is you need to deliver a quality product, and if you feel your product is going to decline in quality if you don't do unit testing (probably bugs), then you need to do unit test no matter how long it is going to take.