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
>> 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-
More information about the Es-discuss