45 ms·

Fast tests are awesome, but hard to achieve - at least for me. TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog post

by andyl 12y ago

Fast tests are awesome, but hard to achieve - at least for me. TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog posts or books.

_pius 12y ago
TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog posts or books. Gary Bernhardt's about as credible on this as one can be, as he's literally recorded hours of himself building working software with TDD. From the article: These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks. If you've watched Destroy All Software screencasts, you know that I'll sometimes run tests ten times per minute. All of my screencasts are recorded live after doing many takes to smooth the presentation out, so you're seeing my actual speed, not the result of editing. I understand disagreeing, but responding to this post with "show, not tell" just makes it look like you haven't read the article.
- gary_bernhardt 12y ago
  Humorously, I already did create a software tool that does isolation automatically. It's called Dingus and it's five years old: https://github.com/garybernhardt/dingus https://github.com/garybernhardt/dingus. It was a terrible idea. It only worked well if you applied the same discipline that you would've had to apply when doing it manually, but it lured you into a false sense of security when using it sloppily. (Dingus is fine when used as a standard mock/stub/spy library, but the automatic isolation features are dangerous and are documented as such in the README.)
- why-el 12y ago
  Ok, Gary's casts are great, but there aren't near as substantial to conclude anything from them in terms of software architecture.
- andyl 12y ago
  I subscribed to DAS and watched all the videos. I admire Gary and other TDD advocates. I believe in the power of fast tests. But still, after watching the videos, I can't do what Gary does. I'm not that good, and nobody I have ever worked with is that good either. For the common developer to achieve Gary-like performance, the tools/frameworks/conventions have got to improve. IMHO. In time I expect this will happen, and that DHH will be proven wrong! :-)
dasil003 12y ago
Isn't this just a reflexive and ignorant response? Have you actually looked at any of the code he's shipped? I mean certainly people should be allowed to write about their experiences without having to face accusations that they've never actually done anything but write.
ebiester 12y ago
It's an acquired skill, and it requires a team that is willing to do it - the trick is to lower impedance toward writing good tests.
akerl_ 12y ago
RSpec has been one of the easiest tools I've ever learned to use. Their documentation is beautiful (and their demo code is actually written as tests), and it's pretty easy to dive right in to writing tests.

by andyl 12y ago

Fast tests are awesome, but hard to achieve - at least for me. TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog posts or books.

_pius 12y ago

TDD advocates: prove DHH wrong with easy to adopt frameworks and working software, not blog posts or books. Gary Bernhardt's about as credible on this as one can be, as he's literally recorded hours of himself building working software with TDD. From the article: These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks. If you've watched Destroy All Software screencasts, you know that I'll sometimes run tests ten times per minute. All of my screencasts are recorded live after doing many takes to smooth the presentation out, so you're seeing my actual speed, not the result of editing. I understand disagreeing, but responding to this post with "show, not tell" just makes it look like you haven't read the article.

gary_bernhardt 12y ago
Humorously, I already did create a software tool that does isolation automatically. It's called Dingus and it's five years old: https://github.com/garybernhardt/dingus https://github.com/garybernhardt/dingus. It was a terrible idea. It only worked well if you applied the same discipline that you would've had to apply when doing it manually, but it lured you into a false sense of security when using it sloppily. (Dingus is fine when used as a standard mock/stub/spy library, but the automatic isolation features are dangerous and are documented as such in the README.)
why-el 12y ago
Ok, Gary's casts are great, but there aren't near as substantial to conclude anything from them in terms of software architecture.
andyl 12y ago
I subscribed to DAS and watched all the videos. I admire Gary and other TDD advocates. I believe in the power of fast tests. But still, after watching the videos, I can't do what Gary does. I'm not that good, and nobody I have ever worked with is that good either. For the common developer to achieve Gary-like performance, the tools/frameworks/conventions have got to improve. IMHO. In time I expect this will happen, and that DHH will be proven wrong! :-)

dasil003 12y ago

Isn't this just a reflexive and ignorant response? Have you actually looked at any of the code he's shipped? I mean certainly people should be allowed to write about their experiences without having to face accusations that they've never actually done anything but write.

ebiester 12y ago

It's an acquired skill, and it requires a team that is willing to do it - the trick is to lower impedance toward writing good tests.

akerl_ 12y ago

RSpec has been one of the easiest tools I've ever learned to use. Their documentation is beautiful (and their demo code is actually written as tests), and it's pretty easy to dive right in to writing tests.