Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
Uncle Bob himself warns against trying to adopt things like TDD and Agile too quickly, as they're intended to be skills and disciplines that one has to practice to become effective at.
I totally agre with this. TDD or even testing is not something you just learn one day and the next you can easily implement it. It's a discipline you need to become good at by practicing. This means that if you are trying to adoot it into every project and you are just getting started it will be a hassle and you will be spending more time worrying about that than working on the actual project. (Personal experience 😂😅)
Why might TDD ever be a bad idea?
Well it would be a bad idea if you are getting started and your are trying to enforce TDD on every project. Depending on the complexity of the project it would be worth it to do that or not. One main issue with TDD is that by implementing it you are creating a lot of overhead, and this can result in delays in your project.
Why is TDD always a good idea?
You will be building a robust project. By implementing TDD, with all it's overhead, you will be setting up a playground to code the best logic you can in a clear way. By using TDD your code will be (potentially) smaller, easier to read, straight to the point and reusable.
By implementing TDD, with all it's overhead, you will be setting up a playground to code the best logic you can in a clear way.
I love this comment, it's so true! When we have a well-tested project, it becomes so much easier to mess around with new features, and find the best way to add them to the project.
Writing tests first really forces us to break the logic down into the simplest possible operations, which naturally leads to cleaner interfaces and more self-documenting code. And clean code is a lot of fun to interact with, just like a playground!
17 year-old self-taught web developer proficient in Javascript and Go, interested in testing, test driven development, agile, code craftsmanship, Docker, microservices
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
Tech enthusiast studying ICT and graduating soon enough👨🏿🎓. Software Engineer in the making, experimenting my way through life. I'm here to connect, learn from y'all and share my knowledge.👊🏿
Writing tests first really forces us to break the logic down into the simplest possible operations, which naturally leads to cleaner interfaces and more self-documenting code.
Yes! that self-documenting part is very important too. If you are working on a piece of code today and have to get back to it in a month, or another team member needs to interact with it, it really makes it easy to understand and continue to work on.
And clean code is a lot of fun to interact with, just like a playground!
It certainly is. I'm still a noob at testing, but I will for sure try to implement it in every project that I think is suitable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agre with this. TDD or even testing is not something you just learn one day and the next you can easily implement it. It's a discipline you need to become good at by practicing. This means that if you are trying to adoot it into every project and you are just getting started it will be a hassle and you will be spending more time worrying about that than working on the actual project. (Personal experience 😂😅)
Well it would be a bad idea if you are getting started and your are trying to enforce TDD on every project. Depending on the complexity of the project it would be worth it to do that or not. One main issue with TDD is that by implementing it you are creating a lot of overhead, and this can result in delays in your project.
You will be building a robust project. By implementing TDD, with all it's overhead, you will be setting up a playground to code the best logic you can in a clear way. By using TDD your code will be (potentially) smaller, easier to read, straight to the point and reusable.
I love this comment, it's so true! When we have a well-tested project, it becomes so much easier to mess around with new features, and find the best way to add them to the project.
Writing tests first really forces us to break the logic down into the simplest possible operations, which naturally leads to cleaner interfaces and more self-documenting code. And clean code is a lot of fun to interact with, just like a playground!
Darn, nobody wants to play devil's advocate.
Hahaha, I guess not😅
Yes! that self-documenting part is very important too. If you are working on a piece of code today and have to get back to it in a month, or another team member needs to interact with it, it really makes it easy to understand and continue to work on.
It certainly is. I'm still a noob at testing, but I will for sure try to implement it in every project that I think is suitable.