The problem with TDD is sometimes, you don’t know if the thing that you’re writing is the right thing. So evertime you modify or completely remove those codes, you also do it to the corresponding tests. It doubles your effort and time to deliver your output. Now I only add tests when I know the structure of the files and packages are fairly stable and not change very often.
That's fair, there's a pretty interesting talk by Ian Cooper where he recommends just writing the tests to help get the general functionality working, but then removing them in favor of business logic tests so we don't end up with the maintenance burden that you mentioned. At the end of the day if a technique isn't helping us achieve our development goals, then we don't need to keep using it
Nice denostration. My personal opinion is that, true TDD is nothing but a waste of time and repo full of codes that ultimately get removed. Unit testing, however, is absolutely necessary. All they needed to do is to drop the philosophy that says "If there is no test, there is no code to write". Assuming that I can write tests correctly but I can't write business logic correctly is insane.
In my experience, I quite like TDD as a reliable method for getting tests into the code base, but to be honest I'm just happy when I see unit tests. If people write nice tests after the source code, that's a win too 😁
Good point, in my experience TDD on its own is a bad way to architect software. It's better to start working out a basic concept with interfaces and design patterns. TDD is more useful when it comes to iteratively building the codebase
Great Video !!
Explained TDD in very simple way.
The problem with TDD is sometimes, you don’t know if the thing that you’re writing is the right thing. So evertime you modify or completely remove those codes, you also do it to the corresponding tests. It doubles your effort and time to deliver your output. Now I only add tests when I know the structure of the files and packages are fairly stable and not change very often.
That's fair, there's a pretty interesting talk by Ian Cooper where he recommends just writing the tests to help get the general functionality working, but then removing them in favor of business logic tests so we don't end up with the maintenance burden that you mentioned. At the end of the day if a technique isn't helping us achieve our development goals, then we don't need to keep using it
Nice denostration. My personal opinion is that, true TDD is nothing but a waste of time and repo full of codes that ultimately get removed. Unit testing, however, is absolutely necessary.
All they needed to do is to drop the philosophy that says "If there is no test, there is no code to write". Assuming that I can write tests correctly but I can't write business logic correctly is insane.
In my experience, I quite like TDD as a reliable method for getting tests into the code base, but to be honest I'm just happy when I see unit tests. If people write nice tests after the source code, that's a win too 😁
They always say TDD is not about test but design, yet never seen a proper tutorial using it as design tool 🤔
Good point, in my experience TDD on its own is a bad way to architect software. It's better to start working out a basic concept with interfaces and design patterns.
TDD is more useful when it comes to iteratively building the codebase