TDD helps facilitates the process of building up of confidence in the product. However, the value it adds is contextual in the sense that if a product is not well defined and at a certain point of maturity then it may not be helpful to shift gears and adopt TDD.
But fundamentally no one should ever be trying to merge code that hasn’t been unit tested. If they are, that is a huge problem because it shows arrogance, ignorance, willingness to kick-the-can-down-the-road, etc.
From an engineering perspective the problem is simple: if you’re not willing to test your solution then you have failed to demonstrate that you understand the problem.
If you’re willing to subsidize poor engineering then you’re going to have to come to terms with adopting TDD eventually, at some stage of the project’s lifecycle, because, you have created an environment where people have merged untested code and you have no way to guarantee to stakeholders that you’re not blowing smoke. More importantly, your users care. Because your users are trusting you. And you should care most of all about your users. They are the ones paying your bills. Be good to them.
But fundamentally no one should ever be trying to merge code that hasn’t been unit tested. If they are, that is a huge problem because it shows arrogance, ignorance, willingness to kick-the-can-down-the-road, etc.
From an engineering perspective the problem is simple: if you’re not willing to test your solution then you have failed to demonstrate that you understand the problem.
If you’re willing to subsidize poor engineering then you’re going to have to come to terms with adopting TDD eventually, at some stage of the project’s lifecycle, because, you have created an environment where people have merged untested code and you have no way to guarantee to stakeholders that you’re not blowing smoke. More importantly, your users care. Because your users are trusting you. And you should care most of all about your users. They are the ones paying your bills. Be good to them.