pull down to refresh
30 sats \ 0 replies \ @elysia OP 29 Dec 2023
I am familiar with Test-Driven Development (TDD) and understand its principles and various interpretations by practitioners. Despite this knowledge, I find myself seldom using TDD, except in two specific scenarios:
- When addressing bugs in an existing codebase, I use TDD to first create a test that replicates and isolates the issue. Afterward, I proceed to resolve the bug and perform any necessary refactoring.
- When enhancing an existing feature with a new use case, I treat the absence of this case as a bug and apply the same approach as in the first scenario.
However, I refrain from employing TDD for developing new features from scratch. This approach does not align with my mental model and does not enhance my efficiency or code quality. It neither contributes to producing more or more valuable tests nor brings me satisfaction.
While I have my own methodology that is distinct from TDD, I still prioritize writing quality tests and maintaining good coverage. It's important to recognize that TDD is not a one-size-fits-all solution and should not be mandated for developers who prefer alternative methods. Like choosing a specific Integrated Development Environment (IDE), employing TDD should be a matter of personal choice. The ultimate objective is to achieve a well-tested codebase, safeguarded against regressions. The means to achieve this goal should be flexible.
It's a misconception to equate TDD with the practice of writing tests. One can maintain a codebase with robust tests without adhering to TDD principles. In fact, the presence of tests in a codebase does not indicate whether they were developed using TDD.
TDD should be viewed as a personal practice rather than a team requirement. Team practices encompass activities like writing tests, code reviews, and automated continuous integration (CI). The individual choice of practicing TDD does not directly impact the team's dynamics. If I claim to use TDD, there's no verifiable way for the team to confirm this without resorting to micromanagement.
For those who are proponents of TDD, it's important to respect individual preferences and not impose this practice on others. TDD, at its core, is a personal methodology, not a collective mandate.
reply
0 sats \ 0 replies \ @NoStranger 31 Dec 2023
For what I know, TDD is actually used in environments where the expected output is always predictable and it's purely based on data.
A friend who work on medical software has a suite of test defined in advance and they just need to make sure the code work as intended.
Many who fails misuse it where it's almost impossible to work with precise outcomes.
When I use unit tests, I do to ensure that code I've written and is already working, keep doing what I want after I change other related parts in the future.
reply