Live data from Hacker News

TDD is dead. Long live testing.

david.heinemeierhansson.com

151–160 of 166 posts

Re: TDD is dead. Long live testing.

#151
post #95

Earlier quoted context omitted.

You really don't want to be surrounded by those people. They'll make you hate your life. Unless you are one of them.

You would hate your life if you were surrounded by TDD fanatics? Would you love your life if you had to change huge applications with 100k+ LOC without any kind of testing and if anything breaks at the client, it's your fault? TDD didn't appear out of the void because some wankers want to deride everyone else, it's the ONLY WAY to have tests in the business world because if the features are developed first, the busin…

I think fanatic and zealot is the key word.

I'm more of a pragmatist. I think one size fits all is a bad strategy, and different projects have different needs.

There is nothing I hate more than working with people who passionately believe that there is only one true way to do something (like testing) and believe the process and 'craft' is more important than other factors like, say, delivering business value.

There is a lot between your extremes of TDD and no tests at all. And when I hear a developer say some methodology is the ONLY WAY I find it's best to run, not walk.

Re: TDD is dead. Long live testing.

#152

Earlier quoted context omitted.

Yes, I've known about the headless proposition for a while. Splitting front-end and back-end tests is desirable. > Worst of all, headless browsers still can't truly test that "the user experience is correct." This is the claim from the old Joel Spolsky article about automation tests but should not be the ultimate dealbreaker. Nobody claims you should rely on automation-tests 100%. Automation-tests test functionality…

> Splitting front-end and back-end tests is desirable. I don't feel confident without integration tests. An integration test should test as much of the system together as is practical. If I test the client and server sides separately, I can't know whether the client and server will work together properly. For example, let's say I assert that the server returns a certain JSON object in response to a certain request. T…

> I don't feel confident without integration tests.

Nobody does. Having said that, my unit-tests are a-plenty and they test things in isolation.

My integration-tests are limited to database interaction with the back-end system only but do not test near-end-to-end to avoid overlap with my unit-tests.

I have another sets of functional-tests that use Selenium but with minimum test cases written for it only to test the happy path (can I create a user? can I delete a user? There is no corner cases tests unless we found that they're a must) in most cases because it is expensive to maintain the full blown functional tests.

Corner cases are done at the unit-test or integration-test level.

Re: TDD is dead. Long live testing.

#153

> 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…

> We see him, time and time again, sniping at people who outgrow those patterns but still want to use Rails.

To me it seems more like the pattern proponents who are sniping at those who find MVC to be sufficient. Take for example the recent discussion that dhh participated in:

* The post's title: "Rails - The Missing Parts". Good start - establish your position by claiming that Rails is defective in that crucial parts that everyone requires are just missing.

* "We’re solving these problems with 3 concepts we believe should be part of any “Advanced” Rails deployment". Now try to convince people that if they aspire to anything 'advanced' then they simply must be adding in these additional bits, no questions asked, no two ways about it.

dhh's "sniping" response?

"Whatever floats your boat, though. If this is what you prefer, great. But please hold the "beginner's version" crap. Plenty of large apps are built with vanilla Rails."

So all he's saying is "if you want to do that, go ahead. Just don't try to make out that Rails is defective because it doesn't do it by default".

Re: TDD is dead. Long live testing.

#154
post #151

Earlier quoted context omitted.

You would hate your life if you were surrounded by TDD fanatics? Would you love your life if you had to change huge applications with 100k+ LOC without any kind of testing and if anything breaks at the client, it's your fault? TDD didn't appear out of the void because some wankers want to deride everyone else, it's the ONLY WAY to have tests in the business world because if the features are developed first, the busin…

I think fanatic and zealot is the key word. I'm more of a pragmatist. I think one size fits all is a bad strategy, and different projects have different needs. There is nothing I hate more than working with people who passionately believe that there is only one true way to do something (like testing) and believe the process and 'craft' is more important than other factors like, say, delivering business value. There i…

I'm not saying TDD is the only way to write code, I'm saying TDD is the only way to make sure that you will have minimal automated testing.

About your condescending remarks about delivering business value, I'd like to see you delivering business value while working with 10 other people on a tightly coupled 100k+ LOC application with no tests. Do that, then I might take you seriously when you say that the craft and process don't matter.

EDIT: Here's how business is done in some parts of the world. I give you the crash tests for the world's cheapest car: https://www.youtube.com/watch?v=RUdKf0FQgEg .Businessmen will gladly endanger human lives in the name of cutting costs, do you actually think they will allow any kind of software testing?

Re: TDD is dead. Long live testing.

#155
post #151

Earlier quoted context omitted.

I think fanatic and zealot is the key word. I'm more of a pragmatist. I think one size fits all is a bad strategy, and different projects have different needs. There is nothing I hate more than working with people who passionately believe that there is only one true way to do something (like testing) and believe the process and 'craft' is more important than other factors like, say, delivering business value. There i…

I'm not saying TDD is the only way to write code, I'm saying TDD is the only way to make sure that you will have minimal automated testing. About your condescending remarks about delivering business value, I'd like to see you delivering business value while working with 10 other people on a tightly coupled 100k+ LOC application with no tests. Do that, then I might take you seriously when you say that the craft and pr…

> I'm not saying TDD is the only way to write code, I'm saying TDD is the only way to make sure that you will have minimal automated testing.

We'll have to disagree there. It's a fine way. There is rarely just one true way however.

> About your condescending remarks about delivering business value, I'd like to see you delivering business value while working with 10 other people on a tightly coupled 100k+ LOC application with no tests.

I, sadly, do this every day. It sucks.

> I might take you seriously when you say that the craft and process don't matter.

I never said they don't matter.

I'm advocating not taking a black and white view of things, which you seem to be doing. There are more options out there than 100% TDD 100% of the time or skipping testing completely...

Re: TDD is dead. Long live testing.

#156

Earlier quoted context omitted.

It's a lot easier to write unit tests for, you know, units. For example, if you have a date-to-readable-string conversion library, you can test the crap out of it since it's input is a date object and its output is a string. It's a unit of code, so all the testing that's required is unit testing. On the other hand, when the "unit" you are testing relies on six external API's and your own database to work, best of luc…

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 coders, or architecture astronauts, and it unfortunately seems to fall into these dichotomies. Admittedly there are people like that, but mostly through lack of experience. The progression is maybe commonly cowboy coder-> architecture astronaut -> balanced software craftsman.

There's probably a bunch of steps missing on the way and it's not a clear linear path either, but I do like the term of having different durations of pragmatism, than a one-size fits all, "We'll cut corners to be pragmatic, because we're not architecture astronauts".

Re: TDD is dead. Long live testing.

#157
post #72

My biggest problem with TDD is that it tends to take people away from whiteboarding and thinking about architecture and into writing everything as if it were a recursive problem -- write test for base case, code base case, write test for next base case, code next base case, write some significant test case, code general case but often this is completely the wrong pattern for solving a problem. This may be an example…

I recommend you to take a look to the "Growing object oriented software guided by tests" book.

The first assumption you made is about TDD being only unit tests. What if TDD is not only unit tests? It could be that TDD is used in many levels, therefore when you do a more high level test, like an end to end/functional/system test, and there should be at least the idea of that system to start with. It doesn't appear suddenly.

The previous book applies TDD in that way: You get what the system has to do, prepare an idea/design of how the system has to do it and validate it through code. Of course that code is written test first.

Thus experts do not promote TDD only on units, thus "no design at all". You will find the no "BIG design upfront" though, but this is a different matter.

Re: TDD is dead. Long live testing.

#158

I've written software test first, and I've written it cowboy. Writing the tests first leaves me with better architecture and fewer defects. Maybe you do better with the cowboy hat on, I don't.

IMHO, it all depends on how complex your task is and how experienced you are in solving that particular task class. Even the most ardent proponents of TDD suggest that you do spikes (write some throwaway code) in order to see what design is applicable to your problem.

On the other hand, if your task is relatively straightforward, you can anticipate the required API and start with tests first.

Re: TDD is dead. Long live testing.

#159

TDD is so prevalent in the Rails community, it will be interesting to see what happens now that their leader has discredited all the benefits of it.

Nothing. DHH is famous for being opinionated. Things DHH dislikes include RSpec, factories, haml and service objects layers.

Re: TDD is dead. Long live testing.

#160
post #128

Earlier quoted context omitted.

> In Ruby, unit tests stand in place of static compiler checks. I haven't heard a strong argument against them nor a replacement for them. How about static compiler checks? :)

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.

Post reply on HN