Hi Mark, the reason why some things don't match it is because you still have the Waterfall testing view. In Agile testing is talking about testing units of behavior, not units of code. To prove it, I added the link to the definition of Unit Test from the Agile Alliance, it was formed by the people that created and signed the Agile Manifesto: "Origins of Agile Alliance: The group of seventeen people that gathered in Snowbird Utah February 11 – 13, 2001, and crafted the Manifesto for Agile Software Development referred to themselves as the Agile Alliance."

So, that's why a unit test according the Agile definition can be an "e2e test", because it defines a unit as a unit of behavior, not code. The implementation details are up to the developer. Testing a unit of behavior means that the test should break if, and only if, that behavior breaks. The code should be able to change without breaking the test.

But the Waterfall defines that there are some tests that are implemented by developers, and some by QA teams. Furthermore, as I said, they are to test code, not to test behavior, so they fixed it. In this definition, the unit test tests one unit of code, that means that the test should break if, and only if, the code breaks. A completely different focus.

Furthermore, you show a link to Kent C. Dodds. What says Kent C. Dodds about testing? The testing trophy, right? Not a pyramid. He realized that the typical, most well-known way of tackling tests was wrong, so the pyramid is mostly useless. Just that he was years behind what the Agile Alliance wrote. (BTW, I went through KCD teachings before learning about the original Agile teachings)

So, what do you think? Does it change the way in which you think and tackle tests?