Test-driven development is helpful, but it misses the mark in certain key areas

[00:00] Test driven development does not do in [00:01] my experience a good job of testing for [00:03] negative outcome, right? It's, you know, [00:06] write the code, write the or write the [00:08] test, make sure that the test says it [00:11] fail, write the code, the test passes, [00:13] cool, go on to the next thing, right? [00:14] No, no, no, no. [00:16] Test passes, great. Now, what could go [00:18] wrong, right? What are the other [00:19] scenarios? How do you write tests for [00:21] those? That kind of stuff. TDD is not [00:22] great at pushing people in that [00:24] direction. [00:26] Second problem with TDD is it's, in my [00:28] opinion, too localized. When I write my [00:31] TDD tests, when I write my localized [00:32] tests, I'm writing my tests to test that [00:36] the code does what I think the code [00:37] should do, [00:39] right? And if my understanding of what [00:41] the code should do differs from what [00:43] somebody else on the project thinks the [00:44] code should do, and our code are [00:45] interacting with each other, then the [00:48] set of things as they talk to each other [00:50] end-to-end is not going to work. But, [00:52] it's not possible for us to do that each [00:55] individually. You've got to have [00:57] end-to-end tests for that to happen.