3 ms·

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 d

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

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