Neil Mix nmix at pandora.com
Sun Aug 17 18:55:30 PDT 2008

>> It's all about time spent.  A large app is impossible for a new-hire
>> programmer to comprehend end-to-end.  We mitigate this by using unit
>> tests as a safety barrier, but over time our tests have grown to take
>> about 10 minutes or so to run.
> A test *suite* with a lot of asynchronous testing could potentially
> take 10 min to run. The test runner could probably be modified to
> allow it to continue when async callbacks come back sooner (e.g
> Selenium's "waitForCondition")

There's a few assumptions inherent in this observation that don't hold  
true for our test suite.  But that's beside the point.  Even if we  
shave off an order-of-magnitude through tricky optimizations, the test  
runs are still time I'd like to spend elsewhere.  As I said, work  
styles vary, mine likes to use types as a tool to speed up engineering  

> A test *case* should normally run in under one second.
> A new feature/change shouldn't have many dependencies; it should be
> simple to unit test.

Should, yes.  Does...well... I'm not always a perfect programmer and  
architect.  (Rarely, actually.)  I need a little help sometimes.  ;)

There's a mild undertone to your statement that I'm wary of, which is  
the idea that "you can work around problem X by being a better  
engineer." While true, it presumes that I'm capable of being a better  
engineer than I am now.  But what if that's not true of me?  What if  
I'm already performing to my utmost?  If I have trouble working around  
a problem, and a language feature can help extend my capabilities,  
well you can see why I might be in favor of that feature.

>> That's way too long to wait for a
>> pesky misspelling bug.
> I could see how autocomplete could use typed programs to provide
> warnings (squiggly red underline).

Yeah, that's always nice to have.

>> To the extent that there's static type
>> checking available to catch errors early on, it's a huge productivity
>> gain. (Although not necessarily one that's easily noticed -- one  
>> tends
>> not to see the problems that grow and kill slowly.)
> The compiler is not a substitute for unit tests.

No argument here, and I was very careful to avoid implying that.  When  
I said "grow and kill slowly," I was referring to length of edit- 
compile-test-debug cycles.

More information about the Es-discuss mailing list