If you use Git, try developing each new feature in a new branch, try keeping your feature branches small enough so that they can be started and merged back into master in a single sitting, delete all dead end branches which will never be merged, and never break master or switch to a new master which has a fewer number of completed features than the one you started with.

It depends upon your language and setup. When programming in a language like C there are no costs to including tests as static inline functions inside of the header file because the compiler won't bother to include this code in the final binary of anything which doesn't reference them.

The primary benefit is that, if you need to make a copy to test multiple versions of an API concurrently without branching the code repository, then you won't need to also copy and rename the corresponding unit test file as well.

This is just a strategy I use to increase the probability that I will maintain complete test coverage when experimenting with the design of an API during early development, but like all strategies it won't be universally applicable for all scenarios.

I think whether or not unit tests save you time depends on your development methodology.

They work well in conjunction with pure functional programming, where one might write a 10 line function, and then a 2 line test below it in the same file, where the test is just a boolean function equality test returning whether or not the primary function returned the expected return value when it was called with a handful of input parameters.

I would agree that writing unit tests for non-determinsitic input-output code or writing unit tests in a seperate file or folder than the code being tested can be a waste of time, but if you have your build system setup to automatically parse unit test signatures from your modules and automatically generate a custom binary to call them, they can be a convenient way to clarify an API and make it feel more stable during the process of writing it.

They are not so bad if you are doing modular functional programming and write your test functions as pure boolean functions accepting no arguments in the same file as the code they are testing. Then you can do a small amount of meta programming by writing a program to parse the function signatures of each module, build a list of your unit test signatures, and write them out to a new code file which prints their name and calls all of them in order, raising an error if any of them do not return True or 1. This reduces a lot of overhead associated with maintaining working unit tests. If you write your tests in the same file as the code they are testing, you won't accidentally loose any of them when a file gets renamed or moved.

They break stupidly when code changes, and people defend them saying "Oh, well, good unit tests don't do that"

They don't break stupidly if you are doing modular functional programming and write the unit test functions in the bottom of the exact same file as the functions they are written to test. This lets you keep related logic in the same place and automatically generate unit test binaries by parsing function signatures rather than creating them manually.

However, if you put your unit test functions in a different file or folder than your primary source code, then yes they will breakly stupidly whenever you need to rename things, as you will have to many more locations in which to remember to change the name.