[metadata]

That might work for you, but is a bad idea in 99% of cases (I am not implying that most code has tests in place). I guess your code changes very rarely. If you have to change something in core part of application with a lot of dependencies, good luck. Also, when several programmers are working on the same part of code (perhaps in a span of 5-6 years), they will need some time to understand code to be changed, then think more where something might break if they change it. At the end, they will lose a lot time and still not catch all the interactions with other code. It took me a lot of time to understand why people want to write tests first, then code. It was more natural for me to make optimal code, then test expected/unexpected inputs and edge cases. The answer turned out to be that code ends up much cleaner and all code paths end up tested properly because you never write a single line of code which isn't explicitly there to satisfy a test.