The earliest proponents I know of - the ones writing XP books back in the '90s - had a very flexible definition of "unit" and assumed that you would vary the scale according to your needs. So some units might be low level components like data structures, but others might be large modules that included a lot of moving parts, up to and including actual databases.

The world has moved on now, and "agile" no longer means "use your own best judgment." It's become a carefully catalogued list of rules and prescriptions and definitions and dictums.

Which, come to think of it, is an excellent example of memetic natural selection. "Use your own best judgment" is a meme that is uniquely poorly adapted to survival in an ecosystem that consists largely of people jabbering back and forth on the Internet like we are right now. You can't base a rollicking good fun argument or a strongly worded blog post on something like that.

> The earliest proponents I know of - the ones writing XP books back in the '90s - had a very flexible definition of "unit" and assumed that you would vary the scale according to your needs. So some units might be low level components like data structures, but others might be large modules that included a lot of moving parts, up to and including actual databases.

It's actually a fairly strict definition, it's just not from the angle that people like to go with (as shown even by your description here): It's a semantic/conceptual unit, not a syntactic unit.

One of my co-workers eventually got it when I told him to completely forget about all the code he's written, then pretend there was a library he could include that did exactly what he wanted. He came up with a single function with a simple set of arguments, that would be used twice, and I stopped him there with something along the lines of: "Okay, that's your API. When you write the code that actually does this, put this function in one separate file and only import this one function in the code and the tests. Now it doesn't matter how you break out the internals into other functions or classes - it's a conceptual unit, not necessarily a single function."

> The world has moved on now and most programmers are duct taping parts together so unit testing no longer has a place in this world.

Even on business-domain level components there are often simple routines which can and should be tested. Larger routines should be built up from smaller ones. Divide-and-conquer is a fundamental engineering principle.

If there are no such small-enough-to-be-tested routines, then the code is not being written with testing in mind. If all your functions are hundreds of lines long, then yeah it's hard to write unit tests!

Occasionally, yes.

But if you're job is to convert JSON to DOM nodes using React, then no.

In this world, what's more likely to go wrong is that one element overlaps another when zoomed to 122% on IE 11.