IT REALLY DEPENDS ON WHAT YOU ARE DOING
The most accurate comment on the thread and you get down voted!
Me too!
TDD is dead. Long live testing.
161–166 of 166 posts
Re: TDD is dead. Long live testing.
#162Earlier quoted context omitted.
The most accurate comment on the thread and you get down voted!
Me too!
People like talking about the reality of implementing design patterns but leave out huge variables, like what is being built.
I think his article highlights something else about FAD design patterns, hype and pressures. The amount of GUI developers I met running around yelling TDD was amusing, and refreshing meeting people who do what is right instead of implementing hype-patterns... new word? :¬)
Re: TDD is dead. Long live testing.
#163Earlier quoted context omitted.
Agreed. Unit testing requires units. I also agree that being pragmatic is generally the way to go, but that kind of pragmatism has limits. If I'm too focused on short-term pragmatism, I will let the issues of external systems infect mine. If I'm being longer-term pragmatic, I'll try to keep my code relatively clean and reliable, no matter how kooky the things I'm integrating with. For example, the first REST integrat…
Short-term pragmatism and long-term pragmatism. Excellent concepts that I've never thought to quite express. It seems you can always 'win' an argument in software engineering or TDD by talking about taking the 'pragmatic' solution, or the 'proper' solution. It often seems rather arbitrary whether to build something properly now, or introduce some short-term technical debt. It's easy to accuse people of being cowboy c…
That path you describe was definitely mine. I think the cycle driving that change is something like:
Things seem great -> I'm ignoring a problem -> Ok, there really is a problem -> I hate the problem -> Look, a solution! -> The solution is the best thing ever! -> Ok, I've taken it too far -> Things seem great.
Regarding the arbitrariness of building something right versus taking technical debt: to me that's great grounds for experimentation, as long as I can trust business stakeholders to give me room. At my last startup, we sometimes took on substantial amounts of technical debt, because I knew could always trust my cofounder to give us the room to clean up our messes when it became necessary.
But in a more pathological business setting, I'd be an absolutist. No technical debt! Never! Because I've seen too many places take that long slide from a little technical debt to an enormous low-productivity snarl. And then they just accept that as normal, generally for the rest of the company's life.
So I think a number of these engineering arguments are framed too narrowly. People often end up cowboy coders or architecture astronauts because that's what's working for them in their circumstances.
Re: TDD is dead. Long live testing.
#164Earlier quoted context omitted.
Still not an adequate replacement for unit tests. The compiler can prove that your code is correct but not that your logic is.
In the same way that writing a unit test for something proves your logic is correct? This is not intended as a snark or something. Just stating the obvious that your unit tests are no silver bullet to a working correct piece of software. My 2 cents: Combine static(ish) typing with tests and a number of (semi-manual) test scenario's and you get a few steps closer to a correctly working piece of software.
Manual testing is what really confirms that your code is working properly. Automated testing verifies the conditions necessary for your code to pass manual testing. The real value of automated tests is for when you need (or someone else needs) to come back and change something.
I don't think static typing is necessary in that case, but I understand it has benefits in some situations.
Re: TDD is dead. Long live testing.
#165> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. This is DHH's central argument, he is once again de…
Isn't it simple? Passing unit tests by definition don't guarantee that your software works. Passing system or acceptance tests do.
Unit tests are still nice to have, which DHH doesn't seem to oppose. Along with good documentation, good unit tests may help keep things maintainable for developers themselves. But they are far from essential, so depending on time constraints and project complexity they may just not make sense to spend resources on.
Re: TDD is dead. Long live testing.
#166> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. This is DHH's central argument, he is once again de…
> In Ruby, unit tests stand in place of static compiler checks I think you have it backwards. Non-ruby developers often use static compiler checks as a replacement for proper unit tests.
Static compiler checks are free, while unit-tests cost initial effort and later maintenance.