When you have to edit a 100+ line method but you discover that it has 0 test coverage.
Feels bad :/

great! Sounds like a perfect time to fill this gap and walk an extra mile - split the method into smaller ones to
a) make it maintainable
b) make it testable
c) make it extensible
d) make it possible to implement the changes you needed in the first place.

I ll add that rule of single responsibility should be applied not only to OOP classes, but to functions as well.
Let's do just one job in function, and do it well! (And tested)

@darkwind I'd say it applies from smaller to larger scale, so functions first, classes later.

When you find a 10k LoC class called pretty much InitProject and that it only works when deferencing its instance in a single thread and somehow, it's the way each services of the company's core products use it... and of course this pile of feces is not tested lol.

Just delete it, mate! It's not worth loosing your sanity.

I would consider an endToEnd test first - before doing a unitTest.

I've worked with extensive unit-testing in the past - but I rarely find the problem to be in the core function - it's often somewhere else in the chain.

If you have a web site the problem is rarely within a specific function - but rather that some viewTemplate calls the function when it shouldn't.

One example:
Let's say you have a dateFormatting-function. Used on a website that's supposed to display blog posts with a publicationDate - and IF it was edited then it's also supposed to display an editedDate.

Then the problem that occurs most often is that the viewTemplate logic forgot that the editDate-HTML shouldn't even render if the blogpost has never been edited.

And no matter how many tests you have for your DateFormatter function outpuitting empty strings if it input is null - that will not fix the issue with the HTML being renderd with a label for "Edited" showing when it has no value.