5 ms·

That bullet point surprised me. It comes right after "110K lines of code. A small number given what it does"; to me this reads like they didn't write tests beca

by aturek 12y ago

That bullet point surprised me. It comes right after "110K lines of code. A small number given what it does"; to me this reads like they didn't write tests because that would add complexity. Can any SO devs give us more details on "not many tests"? Or how many bug reports get filed vs rate of change of software?

jc4p 12y ago
The things that obviously should have tests have tests. That means most of the things that touch money on our Careers product, and easily unit-testable features on the Core end (things with known inputs, e.g. flagging, our new top bar, etc), for most other things we just do a functionality test by hand and push it to our incubating site (formerly meta.stackoverflow, now meta.stackexchange). You can look at reported bugs here: http://meta.stackexchange.com/questions/tagged/bug http://meta.stackexchange.com/questions/tagged/bug -- it's pretty frequent, at least one every couple of hours or so. The last commit in our "Tests" project was 14 days ago, where as the last commit in the code base was 4 minutes ago.
- jacques_chester 12y ago
  You should come down our way and do a tech talk about it. If only for the wailing, gnashing of teeth and rending of garments.
  - jc4p 12y ago
    Your people would literally murder me. Are you back from west coast / toronto?
    - jacques_chester 12y ago
      I am, yeah. We do tech talks every Tuesday. I can promise free food that's not as good as yours.
  - mistermann 12y ago
    Indeed, they seem to have achieved what many have said is literally not possible. Also, some might remember when they had Uncle Bob on the podcast, the topic being unit testing, and iirc Bob preaching the gospel (~ you must write plentiful unit tests, or else) and Jeff and Joel (especially) more or less saying they don't quite get why. (Am I remembering this story correctly? I swear that's how I remember it.)
    - jacques_chester 12y ago
      It's been my experience that outside-in TDD seems like impossibly strict nonsense until you do it with someone who is good at it. Then after a while it seems like an obvious way to work.

by aturek 12y ago

jc4p 12y ago

The things that obviously should have tests have tests. That means most of the things that touch money on our Careers product, and easily unit-testable features on the Core end (things with known inputs, e.g. flagging, our new top bar, etc), for most other things we just do a functionality test by hand and push it to our incubating site (formerly meta.stackoverflow, now meta.stackexchange). You can look at reported bugs here: http://meta.stackexchange.com/questions/tagged/bug http://meta.stackexchange.com/questions/tagged/bug -- it's pretty frequent, at least one every couple of hours or so. The last commit in our "Tests" project was 14 days ago, where as the last commit in the code base was 4 minutes ago.

jacques_chester 12y ago
You should come down our way and do a tech talk about it. If only for the wailing, gnashing of teeth and rending of garments.
- jc4p 12y ago
  Your people would literally murder me. Are you back from west coast / toronto?
  - jacques_chester 12y ago
    I am, yeah. We do tech talks every Tuesday. I can promise free food that's not as good as yours.
- mistermann 12y ago
  Indeed, they seem to have achieved what many have said is literally not possible. Also, some might remember when they had Uncle Bob on the podcast, the topic being unit testing, and iirc Bob preaching the gospel (~ you must write plentiful unit tests, or else) and Jeff and Joel (especially) more or less saying they don't quite get why. (Am I remembering this story correctly? I swear that's how I remember it.)
  - jacques_chester 12y ago
    It's been my experience that outside-in TDD seems like impossibly strict nonsense until you do it with someone who is good at it. Then after a while it seems like an obvious way to work.