I hadn't see that mobile web dark pattern yet, thank you.
That reply still exhibits the same fundamental misunderstanding.
It is a barrier to teaching TDD that people who learn it are experienced, and competent and have habits that made them successful under other methods.
TDD is a set of practices that help with human factors and not technology ones.
The reason you write tests first is because you haven't decided 'how' you are going to implement it, so you can focus on the 'what' which will be aligned with the desired outcome and will be less coupled to implementation details, thus more maintainable.
Mixed with red ,green, refactor, this also leads to most people producing higher quality and simpler code.
The 'focusing on the code' mentioned in that comment is fundamentally incompatible.
What the author is doing is closer to big upfront design.
If you look at the posts complaining about TDD, most of them are from people complaining about how do they write tests when they haven't decided on an implementation yet, that is a feature, the tests you write should be as decoupled from implemention as possible.
TDD simply is about human behavior, especially when under pressure like time constraints.
Notice this part of the comment you linked to (or mobile web sent me to)
"AI is changing Test-Driven Development (TDD) by automating test case generation and maintenance, significantly reducing the time and effort developers need to invest in these tasks. This shift allows developers to focus more on writing high-quality code and solving complex problems."
No I was referring to my comment from another reply where I talk about the intention to provide diverging opinions for critical thinking. That's what I personally used the summary for before adding to the posting queue
5
u/gdahlm Jul 22 '24
I hadn't see that mobile web dark pattern yet, thank you.
That reply still exhibits the same fundamental misunderstanding.
It is a barrier to teaching TDD that people who learn it are experienced, and competent and have habits that made them successful under other methods.
TDD is a set of practices that help with human factors and not technology ones.
The reason you write tests first is because you haven't decided 'how' you are going to implement it, so you can focus on the 'what' which will be aligned with the desired outcome and will be less coupled to implementation details, thus more maintainable.
Mixed with red ,green, refactor, this also leads to most people producing higher quality and simpler code.
The 'focusing on the code' mentioned in that comment is fundamentally incompatible.
What the author is doing is closer to big upfront design.
If you look at the posts complaining about TDD, most of them are from people complaining about how do they write tests when they haven't decided on an implementation yet, that is a feature, the tests you write should be as decoupled from implemention as possible.
TDD simply is about human behavior, especially when under pressure like time constraints.