Motivate co-working on unit tests

I am a developer and I have adopted Test Driven Development (TDD) approach as it is one of the ways I believe I can reduce the accumulation of Technical Debt. At many occasions, when we are starting a new project, the new project needs to be shipped out as soon as possible either because it is a 'evolutionary' prototype that requires a quick feedback from the consumers/stakeholders or it is time critical piece of software. In such occasions, I am confronted with the idea that unit testing will just use time and should be avoided.

As TDD proponent, I do not agree with that. Because going without including unit test in project is technically writing legacy code and starting the tech debt right away. In that kind of situation, I do the following things to convince my team members we should add unit tests:

• I state that I like to write test as this gives me confidence on the code I write as I do not have to argue with BA/QAs about the code quality. After I have said that I would add the unit test in my application. I also mention that writing unit test is good software development practice.
• I then elaborate why adding unit test is time saver for me rather than time hogger by providing an example. I am going to discuss briefly about how I put a real example forward which is an API backed by EF. The controllers, mangers etc are built. Before I can say that I was done, I would need to test the api I built. If I do not have unit tests, I would fire up Advanced Rest Client (ARC) or PostMan or something similar and start sending request while the application is running locally and test the functionality. In doing so, I am expected to keep track of the data if I do not want to type in the data all over again when I retesting the same api. Instead of doing that I could write unit test and my data are there in code itself based on which I can test the functionality and I do not need to re-test the functionality by using some client when I make changes to the app.
• Discuss idea about target code coverage.

With the above descriptions, I would share how I build those tests and team members would agree on the power of the test only to realize that adding unit test early on is at least not only the time consumer, but may well be time saver.