Karen incident in the customer service call center driven development.

If someone hasn't yelled at a minimum wage phone rep over it, it doesn't need to be fixed.

Vibe coding is driving error development

Joke’s on you, I vibe coded my tests too! Now my development is driven by errors in my tests!

With a fun side quest of figuring out if your actual code has the error or the tests!

caught errors, but yes

That's overly broad.

Developmestuction!

Code normally works fine after you write it and then hopefully at least test by hand. The new guy 5 years later, which do not fully grasp the extent of his actions, and the guy reviewing the code also not being too familiar with it, will not make sure everything does as intended.

Tests are correctness guarantees, and requires the code and/or the test to change to pass. They also explain how something should behave to people that don't know. I work in a area where there are so many businesses rules that there is no one person that knows all of it, and capturing the rules as tests is a great way to make sure that rules remains true after someone else comes to change the code.

You know that thing you do, where you write some code and then realize you need a main function to execute it? And then you write your main function, but it's not really your main function, it's a bunch of half commented test code to make sure that the important code works?

Do that in a unit test, and when you're done testing that particular piece, add some assertions and move on to the next piece of functionality. Boom, test driven development.

It's a tool, our job is to collect tools in our toolbox and use them appropriately

TDD is great for when you want a really, really tight interface - whether it's your exposed surface to customers or you've got a lot of people working on something, it makes sense to write the standard and code to it, instead of documenting after the fact

Otherwise... Well, in practice it's an idiot proof methodology. That's useful, but it is a lot of work

Imagine you're writing a front end and that the backend that will be serving the data is not ready yet, or it's down for whatever reason, but you know how the data will look like. In that case you can write a test with hardcoded data as if it's coming from the actual backend, and test several possible cases of the front end logic.

Another example is this: say you have some functionality that's behind some UI that you have to click through; you make a change, the page refreshes and you have to click a bunch of stuff again - until the next change when the page refreshes again. If you have to do this over and over again, things get inefficient. Instead, you can write a test to make sure the functionality handles the data properly and only then go through the UI to maybe test this or that edge case.

Plenty of other examples, but yeah, depending on what you're doing, you might not need tests at all.

My job used to outsource a bunch of dev work to another company and oh boy did those people love their tests. I don't get it. In my case they weren't even using our actual database to pull data from. They had a bunch of fixture files with generic data that they would use to make a temporary sqlite db for the tests. All of the test ran perfectly with that data, not so much with the actual data. The code is there, can't you just read it and know what will happen?

When I write something I'm never not building it and at least checking that it works and trying to break it.

I like testing my helper/utility functions mainly so I can be sure I implemented them correctly. That way I can focus on my main implementation and narrow down where the problems are coming from.

I wrote tests today and found an error in my code. What is that? Development driven test driven development?

Kingdom of Heaven, I believe

I literally do that. With real world customers, and real world payments and real world consequences running through the system, all the time.

I live in fear.