>> 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 tasks. > 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. _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
