TDD is dead. Long live testing

Testing
1

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Latest post about DHH is sure a conversation (or rant) starter. I myself disagree and I am tend to believe, does so thoughtbot.

I’d like to hear your thoughts about it. Is TDD overrated for experience developers?

Ever since I have became aware of TDD, I’ve always challenged it, and it always bit me back when I had a stupid bug I knew I could have prevented if I was better at TDD, so I improved my TDD skills to make sure those happened less. I couldn’t be more happy with TDD and it’s always a good subject to discuss and improve upon. I couldn’t disagree more with what has been stated on this blog post.

3 Likes
2

If you like to write highly coupled code that is hard to test because you gave very little to the thought of proper boundaries… You might be DHH.

If you think testing is hard and think test unit was awesome… You might be DHH.

If you think complicated meta-programming is fun and you should do it… yeah, you know.

If you think MVC + Helpers are all there is, you do not practice OOP and your name might be…

I will stay away from any ad-hominems. The evidence above is damming. If anyone read my blog @ http://rubylove.io I would possibly shout this from the mountain-top:

RAILS IS BLOATWARE - MVC SUCKS COMPARED TO OBJECTS AND SOLID - LONG LIVE TDD - FUNCTIONAL TESTS ARE SCAMS… AND DHH IS TO BE THANKED!!!

Then inside the article it would say DHH has very bad ideas on software craftsmanship, but he might be doing it on purpose as a sort of ‘colbert’ persona. And the only reason I thank him is for allowing me to write shit in ruby, and then plug it in to rails for a living. That and to rescue Rails project after Rails project.

Not to be a fanboy on a fansite, but I will take Ben Orenstien and Gary Bernhardt’s (and now Joe’s) advice over DHH any day.

DHH speaks for Rails, we speak for Ruby.

I am sure DHH is a nice, smart, and awesome guy.

1 Like
3

I write small, single purpose ruby objects, usually with a single public method (that is also aliased to call, so you dont need to remember the method name or use intellesense, and most of my methods are pure functions, data in , data out. Also, if you only have 1 responsibility per class and 1 public method per class, it makes it very easy to alter the internals of your object and NOT break the public api :smile:

Most of my objects are modules, with no state. Occasionally I have a class with state, but then it is always immutable, with the only way to alter it is to return a composite object of the old values and the new values and a new unique object without altering the old one.

I use minitest/spec and I do TDD exclusively (when not hacking/spiking/learning). I prefer unit tests to integration tests. I also TEST PRIVATES, because I write decoupled, stateless code for the most part, there is no 'chains of broken tests because I alter a private function.

I find no problems with TDD and you can pry it from my cold dead hands. I am not trying to create jobs for QA. I am trying to eliminate them.

So there, MY counter to that DHH turdfest of a post meant to draw more attention to himself.

1 Like
4

The DHH and thoughtbot approaches to architecture have been almost diametrically opposed for a while now, so I’m not very surprised by this post.

I’m not leaving Rails any time soon, but it’s kind of scary to see that the guy who probably has final say in most architecture decisions in the one of the most important pieces of my software stack has this view on testing.

I think that a very smart developer MIGHT be able to get away with this approach to testing (I still think it would be preferable even at that stratospheric level to use TDD), but DHH is helping to generate another generation of developers being sloppy hackers.

1 Like
5

I am having quite the throw-down on parley about this. I guess I have just been a thoughbotter @ heart for a long time now. I will say it here, there, and everywhere.

I am a testing zealot. I TDD. I do not want to work at a shop where devs don’t TDD or TDD at the wrong boundaries, which to me is the straw-man DHH sets up to knock down.

He likes coupling. I hate it.

6

I really enjoyed his post and his keynote.

I think he’s really speaking out against the test-first fundamentalism. I don’t enjoy feeling bad for failing to write my tests first. Not that I don’t try… I always start TDD, but I end up writing code first so that I know what I want to test. The whole, “your not a professional unless you do TDD” undertone really makes me feel like an outsider sometimes.

Personally, I don’t like absolutes. I think writing your tests first (not TDD) makes sense a lot of the time. Automated testing makes is a no brainer, but the whole TDD dogma can go away for all I care.

2 Likes
7

I will preface this with I am not attacking you

That is saying it is ok to cheat when your skills fail you (which it kind of is I will concede)

I say that is a failure in your test first habits and capabilities. It says nothing about the practice of TDD.

I don’t have to say I am a TDD zealot I guess. It is quite obvious. :smile:

8

I’m not against TDD… I’m against TDD Dogma. The idea that someone isn’t as good unless they do TDD.

9

and just to be clear: I enjoy discussing this topic and don’t see anything here as an attack. I’m here to learn after all.

10

can we do a blind experiment instead of talking out our butts? (myself included) because I DO think that the best coders, ie, by definition those who write the best code, do practice tdd.

so I propose this. you write some non tdd code, I will write the same problem with tdd code.

i will then delete my tests and tarball it, you tarball yours

then we will let TB pick a judge who does not know which of us wrote what, or which did the tests, or who write the code at all.

deal? :slight_smile:

2 Likes
11

I like the idea, quite a bit actually. I’m not sure I’m that good to begin with though :frowning:

12

I will accept #challengers however you can’t be a test first person who then plays devil’s advocate.

You should absolutely believe what our friend David here is postulating, which I think is something to the tune of:

a) TDD does not lead you to better code decisions
b) The best coders don’t necessarily TDD

I want do this out of the want for the science of it.

1 Like
13

Also, rather than make the original stink I made about DHH’s comments, had I been a better person, I would have said that I feel what he said is highly irresponsible.

The whole having a figurehead say crap like TDD is dead is spitting in the face of a lot of previous hard work in the XP and software craftsmanship communities. I feel it is saying to lazy cut-corner managers and programmers to skip TDD because Moses said so.

I would also ask something very jokingly: If Matz is nice and the inventor and curator of Ruby, and we as Rubyists should be nice because of it, then by contrast, DHH has certainly been accused of saying stupid, arrogant things and not by me. So does that mean Rails developers should follow DIASIAA ?

I think not by the way. I am just genetically disposed to piss people off, probably like someone else I know… :smile:

1 Like
14

Sandi smashes your arguments against tdd, and against small, well encapsulated objects that do one thing, and the use of oo polymorphism like a CHAMP

1 Like
15

Might be stirring the pot here.

It seems like the first statement of DHH’s post sums up his thought’s rather well:

Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.

Test-first is definitely NOT the only way to produce fantastic code. Also, anyone who doesn’t test first is NOT a bad person who should feel bad.

The biggest problem, which the whole first half of his post is dedicated to, is there are many in our community who enjoy making people feel terrible for not testing. There’s a certain self righteousness some show when talking about how “code isn’t real code unless it’s tested”. It’s evident in almost every talk on testing, they all start with “how many of you write tests?”, “how many of you have 75% coverage”, etc. These talks then go on to tell you how great testing is and everything you code you should test first without exception!

So I think the first point is that as a community, the test first dogma is very unforgiving and that’s intimidating. It’s certainly something I wasn’t comfortable getting into.

The second point is DHH definitely isn’t saying we shouldn’t test our code. Tests are fantastic and give us the confidence to continue evolving our systems without destroying the foundations. He’s simply tired of writing unit tests for everything, mocking out all the interactions for the sake of faster tests. He wants to move rails more towards acceptance testing as speed isn’t as much of a concern.

By the way it seems this isn’t stark contrast to the views expressed by thoughtbot or Sandi Metz. Sandi says “The true purpose of testing is to reduce cost”. There is a lot of class methods defined as private, and as such shouldn’t be tested as you should only test your objects public methods.

I’ve been enjoying TDD since I’ve started employing it in my own projects. However, I’d be a lier if I said it was all rainbows and sunshine. Acceptance tests and integration tests have been the most successful while I struggle to justify unit testing my router and controllers.

By the way Sandi also always gives a rule and then a list of situations in which you should break it. Saying that TDD is the only option seems short sighted and in the end my cost more then it’s worth. I think that’s the point DHH is trying to convey is that unit testing every single line of code is too much.

We should aim to write the best code we can, for the lowest cost.

Testing helps us achieve that.

Being religious does not.

5 Likes
16

Sandi TDDs.

My point is that the Ruby community shames people who don’t test because it IS unprofessional. Shame is powerful.

You are putting up a straw man… “He’s simply tired of writing unit tests for everything, mocking out all the interactions for the sake of faster tests. He wants to move rails more towards acceptance testing as speed isn’t as much of a concern.”

That highly coupled code is a result of the way you code and not testing. You also don’t mock interactions out “to make tests faster” you do it because unit tests do not test beyond their “unit”.

I just see straw man after straw man.

By the way I was just banned on RR Parley for expressing these very feelings. I have never had a single post flagged here, so I think there are probably more people here who think like I do.

If you code is hard to test in isolation is it NOT the tests fault. :slight_smile:

17

I think the core of his post is that TDD should not be design, or start before design.

Maybe he personally had a problem where he was writing tests while designing, which is the point of the post.
I think this ideology lines up with Thoughtbot’s playbook rather well – in that there are design phases before code, or tests, are written. At the end of the day, it’s an ideology – a generalization and summation of daily activities and process. It will always have its shortcomings.

18

@Dreamr no one is suggesting that TDD leads to bad code. I TDD. I never said Sandi doesn’t TDD.

The way I got into TDD was with a lot of hand holding. TDD should be the obvious path based on it’s merits. If someone came up to me before I practiced and told me my code is inherently bad, I am unprofessional, and generally shouted abuse in the hope I’d agree with their point of view, I’d think to myself “those TDD guys… are assholes! I want nothing to to with them”.

It seems this isn’t a discussion. You have an opinion. I understand that. Now try and have some empathy. Get people into testing by showing them how awesome it is! Not by making them feel like shit.

3 Likes
19

By the way… your username? The best evah! :smile:

I have a very strongly held opinion after losing many battles with smarter people than myself, yes. For me the debate has happened and XP/TDD won. There has been study after study performed and not one I have seen falls on the side of not TDDing.

My heroes are Kent and Martin And Bob and Conrad, so I am sure you can see why I hold the opinion I do. If you do not know these names and have not read their books, and watched every DAS and PeepCode, et all (and TB!), I don’t think we can have a ‘debate’ on it.

But I still support your right to hack. I however do find the non practice of TDD, unprofessional. They can be great people, smart hacker, et all, but still, it is unprofessional in this day and age.

I am fully award that I am the person DHH is arguing against. I am a TDD zealot, after dodging testing for years, then testing wrong for years, then ‘getting’ TDD and changing my coding style to be a functional, non mutational, collection of single cell organisms that each do a job and 1 job only that you can chain together like unix commands in a compositional fashion in order to achieve my diversity. You will find no conditional branches, they are GOTO for me.

again, love that name!!!

20

I’ll have to respectfully disagree with you. Whether it’s test first, or test after, calling someone unprofessional based on what process they follow is over the top.

3 Likes