[shoo]

technical perspective, ignoring business perspective: resolving the bugs by writing tests is excellent advice, especially once a component is sufficiently complex. get regression tests in place first, so you can sense how may new unknown defects a "fix" for a known defect is introducing. Michael Feathers' book "Working Effectively with Legacy Code" describes one approach.

somewhat political perspective: if the org doesn't value testing or software quality, wait until there's obviously a business need to lift quality. E.g. the CTO is saying things such as "constant defects in component X are destroying most of the value of our product", users complain that the Y feature keeps getting broken in successive releases, customers refuse to renew subscriptions or upgrade to a new version until Y feature works reliably. Then propose the plan to improve QA by setting up an automated regression test suite, to allow refactor-to-test of the offending code to happen in a controlled, low risk way.

[dgelks]

Agree with this totally, additionally if you are unsure if you will proceed with an idea with no users, getting something done and receiving feedback as fast as possible is better than doing it perfectly the first time.

That said at my last company after 12 months we hired a few engineers so we had to transition to requiring tests for new functionality. This was just to stop regressions and make sure we could continue moving quickly.

[brimstedt]

I partly agree with you, but I also think that using debugger/stepping through code/test manually will take longer times in most cases. And it's time wasted that does not produce anything "permanent" - unlike tests.