God I'm getting tired of the whole TDD culture. I get it, testing is good, but we're getting to the point where several major OSS projects fail on common real-world use cases because instead of worrying about the main purpose of a software, devs only worry about satisfying their artificial tests. And when someone opens an issue, it just stays there for months or even years simply because setup & teardown logic for the required tests would be several times more complex than the actual fix.

With TDD that setup/teardown problem would probably not exist.

When devs look at their code and ask "How to satisfy those tests?" instead of asking "How to make this a functional piece of software?" I believe it's mentality that's broken. Tests are a great way to prevent regression and automate various scenarios, but when someone's more about 100% coverage, A+ code quality badges than about what software users need, they're just an annoying TDD evangelist building up their own ego.

@ojrask Bullshit. Looking at some high-profile TDD OSS (Angular, TypeScript, WordPress, Kubernetes, ...), source code to test data ratio is between 1:2 and 1:5. Guess why? Because each test needs a clean environment to run in, and everything that's more complex than a pure (x) => y function requires some logic to first mock the required environment, and then clean up those mocks.

@hitko if you think WordPress has been developed using TDD I would love to hear your definition of TDD.

Starting to use TDD after years of development using "test after the fact" or no testing at all does add difficulties in terms of adding tests that make use of existing facilities.

My point was, that if all those projects were written using TDD from day 1, you would not see problems with adding new tests among the others that already exist.

@ojrask Angular, TypeScrpit & Kubernetes were all TDD from the start, and many recent WordPress code has been written using TDD. And WordPress isn't even the worst of those by tests to source code ratio. Try again.

@ojrask And as @groxx already said, adding new tests isn't meant to cover the code you have, it's to make sure your code does what it should. Using old data to test new scenarios usually only bumps your coverage and nothing else.

@hitko in case something is written tests first but the only aim is coverage, it is not optimal. That is coverage driven development and can result in shitty tests and shitty design.

The folks themselves who came up with Test Driven Development are currently admitting it should've been called Test Driven Design instead, to convey that just mindlessly crunching out microtests is the wrong approach. Red, Green, Refactor, but sadly many skip the last step, where you make sure both the tests and implementation are clean and maintainable.

@hitko in TDD tests are not separate from source code, hence the notion of source-to-test ratio is useless in this context. The tests are part of the application, and should be maintained with the same care as your application logic.

TDD is what you get when software engineers become bureaucrats.

Test-driven development (TDD) principles have certain benefits, but an overemphasis on meeting artificial tests sometimes causes open source software projects to run into problems in certain situations. actual use. Instead, developers should strike a balance between ensuring code quality through testing and completing key software features. This will help ensure the primary purpose and value of the product, while still maintaining long-term sustainability and maintainability.

The source-to-test ratio is nonsensical in TDD since tests are not independent of source code. Like the program's logic, the tests need regular attention because they're essential.