4 ms·

I didn't appreciate unit testing until I started doing development test-first in Smalltalk. You just sketch out the skeleton of your classes with instance vari

I didn't appreciate unit testing until I started doing development test-first in Smalltalk. You just sketch out the skeleton of your classes with instance variables and accessors. Then you write tests the way you want your objects to work (design your API by pretending to use it). Then run your tests, and marvel as the debugger stops on missing methods and lets you create them at that point and continue the test. It's a terrific way to get your code right the first time. I don't know what he's using there at Justin.tv, but most languages that are more rigid (than Smalltalk or Ruby for example) are certainly not quite as nice for unit testing.

abstractbill 18y ago
Sounds great! But in the meantime, I've put a couple of prototypes online, got a bunch of feedback, iterated, and figured out that nobody wanted the thing we designed in the first place. I've moved on to an evolution of the original idea, while you're still focused on getting the first idea to work "perfectly". My point is that unit tests aren't cost-free, and their ROI is awful for most things.
- fizx 18y ago
  That's funny, cause I practice something I'll start calling "cost-free unit testing". Step 1: If you're thinking about how a code api should act, sketch it out inside a test. Step 2: If you're about to jump into a repl and poke at your code, open a unit test instead. Now you've simply replaced other activites at no net cost to you. My core takeaway is that everyone tests their code somehow. You're best off if you can automate that process. Don't obsess over it (I almost never test my html/views), but try to find opportunity.
- swombat 18y ago
  Unit tests don't take that long. If it takes you that much longer to write your unit tests, you must be doing something fundamentally wrong - like perhaps testing the wrong thing or focusing on the wrong kind of testing.
  - Daniel_Newby 18y ago
    It is hard to make inline unit tests when the inputs and outputs are really complicated, like the request/reply data structures in a web framework.
    - swombat 18y ago
      Totally agree, that's why you need good MVC separation and you test those layers separately. The models testing is obvious. What you're referring to there is controller testing. In Rails/Rspec, the way you do that is by mocking/stubbing the models (so you're only testing the controller logic). Then you pass in the parameters that would come in from the web, and check that the controller code (which should be fairly straightforward) behaves appropriately. This article explains this approach quite clearly: http://www.patmaddox.com/blog/2007/9/15/easy-controller-tests-and-expressing-intent-through-expectations http://www.patmaddox.com/blog/2007/9/15/easy-controller-test...

abstractbill 18y ago

Sounds great! But in the meantime, I've put a couple of prototypes online, got a bunch of feedback, iterated, and figured out that nobody wanted the thing we designed in the first place. I've moved on to an evolution of the original idea, while you're still focused on getting the first idea to work "perfectly". My point is that unit tests aren't cost-free, and their ROI is awful for most things.

fizx 18y ago
That's funny, cause I practice something I'll start calling "cost-free unit testing". Step 1: If you're thinking about how a code api should act, sketch it out inside a test. Step 2: If you're about to jump into a repl and poke at your code, open a unit test instead. Now you've simply replaced other activites at no net cost to you. My core takeaway is that everyone tests their code somehow. You're best off if you can automate that process. Don't obsess over it (I almost never test my html/views), but try to find opportunity.
swombat 18y ago
Unit tests don't take that long. If it takes you that much longer to write your unit tests, you must be doing something fundamentally wrong - like perhaps testing the wrong thing or focusing on the wrong kind of testing.
- Daniel_Newby 18y ago
  It is hard to make inline unit tests when the inputs and outputs are really complicated, like the request/reply data structures in a web framework.
  - swombat 18y ago
    Totally agree, that's why you need good MVC separation and you test those layers separately. The models testing is obvious. What you're referring to there is controller testing. In Rails/Rspec, the way you do that is by mocking/stubbing the models (so you're only testing the controller logic). Then you pass in the parameters that would come in from the web, and check that the controller code (which should be fairly straightforward) behaves appropriately. This article explains this approach quite clearly: http://www.patmaddox.com/blog/2007/9/15/easy-controller-tests-and-expressing-intent-through-expectations http://www.patmaddox.com/blog/2007/9/15/easy-controller-test...