search

luminousmen / luminousmen.com

2 stars 0 forks source link

https://luminousmen.com/post/rumbling-about-test-driven-development #54

Open utterances-bot opened 1 year ago

utterances-bot commented 1 year ago

Rumbling about Test Driven Development - Blog | luminousmen

Rumbling about my personal experience on using TDD practices

https://luminousmen.com/post/rumbling-about-test-driven-development

mikenac commented 1 year ago

I agree with most of what you have said.

TDD allows you to get that "working" state faster. The raw, terribly formatted, tightly coupled, POC type code can start out in your test, to really see what is possible. It also allows potential consumers our your code to do similar activities quicker.

This allows cheap exploration and possibly a challenge to those very (often speculative) requirements (which should be behavior based). Once feasibility has been established, the code can be refactored into well formatted, loosely coupled, easy to maintain code, while ensuring constant passing tests along the way.

This avoids the pitfall of getting sucked into architecture paralysis before you even know if the operations are feasible in the first place. I have seen this drag projects into obsolescence before their first win.

So, yes, a lot of times code has to be written to answer the question of feasibility. The goal is to do that as quickly and as cheaply as possible, while being able to support risk free refactoring later.