If you are saying it is over the top, then you are not “respectfully” disagreeing.
If you don’t believe me that not TDDing and writing tests in general in unprofessional try getting hired @ TB and tell them you don’t TDD.
What would it prove if I told you that I’ve worked at thoughtbot for almost two years now? Would it change anything if don’t practice Test Driven Development 100% of the time?
1 Like
You might. I do know this. I interviewed at TB 2 years ago and I challenged TDD and I didnt get a call back. I went to Hashrocket, and they had the same requirement.`
I am however convinced that you are inflating your lack of testing. I have spent years working with TB software and I have never seen one without good unit tests 
I doubt a programmer will be hirable unless they practice writing automated test in the next 5 years. It is already close to that.
I’m not sure I had exactly the same takeaway from DHH’s talk as other people might have. The main thing I understood from his talk was a desire to achieve clarity - something everybody here obviously cares about.
IMO I think people may have taken his rant about TDD a bit too literally? I think he mentions a few times that he’s not saying to not test, (and I can’t imagine for a second the folks at Basecamp would adopt such a strategy). It seems like he was just saying to not be dogmatic about your testing and focusing on things like coverage, ratio and speed as a pure indication as to how good your code is, which I don’t think is such a bad thing?
Just to clarify - I am in the TDD camp lol but to be honest I’m not up in arms about what he has to say.
Last week at work, I saw cases of ‘well-tested’ code where IMO there was no obvious sign of better design being applied. What’s more the tests in those examples took longer to understand than the actual code itself (thanks to a mean combination of before blocks, let’s, subjects, mocks & stubs and so on - not cool!). In such circumstances, I’m not impressed with the code irrespective of whether the author applied TDD or not. (Can you be confident of your code changes if you don’t understand what the tests are actually doing?)
As regards to the bigger picture of new developers not pursuing TDD because of this keynote, I doubt that’ll happen and if it does I think it’ll be more likely due to laziness on the part of the newbie (in not finding out what they really don’t know) and/or them surrounded by a poor framework of mentors/advisors who don’t appreciate there may be some value in TDDing.
Whether you like or dislike what DHH has to say about this, he has done one thing and that’s bring attention to the idea of writing clear and understandable code. In fact, more people are talking about TDD now and writing blog posts about why you should do it then before.
2 Likes
Nothing works 100% of the time, and there are varying degrees to which people follow TDD. It’s not a binary thing; it’s a scale. I find myself pretty far on the “tests-first” end of the scale. I know there are plenty of people who find themselves on the other end of the scale. Many of those people manage to produce quality software.
I think it’s important to step back every now and then and remember that TDD is not a necessary ingredient. People wrote software which worked for a long time before TDD existed. Much of the software community continues to write code test-after, or entirely without tests; they continue to produce working software.
I have many reasons for why I believe TDD is better. I also understand that other ideas work, and what works well for me and my team may not work well for every person and every situation. When discussing principles, it’s important to be able to respect the people who make other ideas work, even if their ideas don’t work for you.
People who practice TDD tend to be preachy. I think that’s because TDD is one of many ideas which works best when everybody around you is doing it. Because I work best in the context of a test-driven code base, I’m happier and more effective working on a team which practices TDD. I try to convince the people around me to follow TDD, because I believe it works well, but also because I’ve found I work well that way. This means teams and companies will generally trend towards one end of the spectrum or the other.
It also means that people evangelize tests outside of their team. For example, I’m much less likely to contribute to an open source project without solid tests. This has the end result of creating a community of test-driven open source, because developers practicing TDD are more likely to contribute to projects with tests.
If DHH’s point was to say we should have an open discussion and re-examine the reasons the community uses TDD, that would be useful. If he wants to decrease the amount of name-calling and childishness which occurs between followers of TDD and those who reject it, I’d agree with him. However, he resorted to name-calling and public, angry rants himself, which only serves to further polarize the community.
I you love TDD, don’t resort to DHH’s approach. Don’t call people who don’t test first unprofessional, obsolete, or amateurish. Try to convince them that your ideas have merit using reasonable arguments. If you can’t or don’t want to convince somebody, learn to respect that they’re still members of your community, and many of them write useful software using different methods. See if you can learn from their methods. That’s how we learned TDD in the first place.
14 Likes
I didn’t make this up. It isn’t my idea Joe. Blame Uncle Bob, not me.
My point is that TDDing is done not just through tests, but through the repl, and through the browser. I think DHHs point was that unless it is unit tests, it isn’t TDDing and that doesnt always work.
That is a straw man. I coach people every day for money. I do not make beginners to TDD in tests, but we DO do it via the browser.
Write the code, top down that you wish you had, refresh the browser, read the error, fix it, get a different error, repeat till done.
That IS TDD even though it isn’t automated tests. I also still agree, am I should be allowed to or I will vacate these forums, agree with Bob Martin and Kent Beck.
If Uncle Bob says that people who do not practice TDD and testing in general are unprofessional. then I have to agree with that statement no matter what you say.
I am not a political man, I am a man of reason and truth living in the land of logic.
Teams who test heavily, including ThoughtBot, are professional, teams that don’t aren’t. We are not laborers we are KNOWLEDGE workers, we are professionals, we are white collar. We are much more akin to doctors and engineers than to anything else.
Being professional means you dont ship garbage. You don’t sling mud. You make well calculated guesses to build a product, then you adjust your choices by analytics which are TESTS And if you do that process from the beginning you are doing business via TDD.
If you make rocket software and you do not have tests, you are a danger to yourself and every one around you.
I think a lot of people are ‘arguing the polite argument’, but to me that is like putting creation in science class. A developer who TDDs is not equal to one who doesn’t.
A developer who has habits, like pair programming and tdding cannot be placed into the same bucket as a lazy programmer who just reacts to their world.
I am currently in the process of influencing people on my company to use TDD and one of my main arguments is Kent Beck’s note.
Similar to what @Dreamr has pointed, if you create code that is not tested, you are probably setting up a timebomb that might explode on someone else’s hand with a weird bug that will take forever to debug. If you have a test environment with a fairly good coverage, chances are this will happen less, just because it is much easier to debug something by finding the right test to write, and then fix it.
I disagree with the argument that “people have done software without tests for a long time” because people have done working software for years with Waterfall. It’s just not worth it.
I do agree that the approach to this is just like convincing someone to use a better tool. It is NEVER good to scream at someone “You are unprofessional”. They can be professional, they just lack the understanding of why testing is essential and why TDD helps you on that.
I don’t think anyone in this thread is in support of not writing tests.
TDD is not the only way to write tests, it is just one of the processes. If you don’t TDD, it does not mean you don’t write tests! I agree, that developers should utilize tests to “reach a given level of confidence” (per Kent Beck).
Personally, I’d love to see some statistics on code quality that was written using “test first” vs “test later” approaches.
…but doing TDD is the best way to assure tests are correct. Hence why it has an advantage over not using it.
It is much easier to understand what DHH was saying if you read books or watched lectures of peoples he is quoting.
MVC+DCI is future.
Links for video lectures and example here:
https://gist.github.com/izbor/4ae08b0b57e9a810a852