5 ms·

Without automatic testing dynamic languages are not very productive because they do not catch type mismatch errors during compilation time (there isn't one). Wi

by tx 19y ago

Without automatic testing dynamic languages are not very productive because they do not catch type mismatch errors during compilation time (there isn't one). With statically typed languages you get a lot of tiny issues taken care of once you hit magic "compile" button and compiler does some basic sanity checks. Without solid unit tests backing you, activities like removing "obsolete" methods or renaming classes/modules turn into nightmare with duck typed languages.

richcollins 19y ago
We didn't write tests for our last startup and we never had too many problems with bugs. We do write tests for this one and we don't have too many problems with bugs. Tests take almost as much time to develop as the features do. I just wonder if it is worth the time and if other people with startups write automated tests.
- jsjenkins168 19y ago
  I'd say try to plan for how much you will need to scale your code, and also how many others will be working on your code. As your code gets larger, and as you start to have others working on it (who could break it), unit tests become more important. If you dont foresee either of these happening, then the time investment for tests may not be worth it..
- tx 19y ago
  No difference? That's pretty impressive. I wish I was able to look at your process. Either your engineers are extremely smart and anal about their practicies or your domain is very simplistic (ta-da lists). At my previous start up we had unit tests run on the entire system automatically after every check-in (with CruiseControl) and whenever someone broke a test suite, everybody got an email with name of the offender and diffs of his code against the trunk. We also had a "beer rule" about violatros gettings drinks for everyone, to make the process a bit more exciting.
  - richcollins 19y ago
    Facebook doesn't have an automated test suite. I wouldn't call that a simplistic app.
    - immad 19y ago
      really?! I would be shocked if they dont have at least automated testing on their most critical systems. Whats the source of that info?
      - richcollins 19y ago
        we asked Mark Zuckerberg at Startup School
- jimbokun 19y ago
  Wil Shipley on unit tests: http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html I think what he's saying is unit tests don't add much if you are doing UI type development. It is hard to write unit tests for UIs (web or GUI), so if most of your code is UI code, don't bother. However, if you are writing a library that will be used by a lot of coders, unit tests are probably indispensable. Otherwise, you would never be able to make even simple architecture or design changes (refactoring).
SwellJoe 19y ago
"Without automatic testing dynamic languages are not very productive because they do not catch type mismatch errors during compilation time (there isn't one). With statically typed languages you get a lot of tiny issues taken care of once you hit magic "compile" button and compiler does some basic sanity checks." You're just exhibiting a basic dislike of dynamic languages. Type mismatch errors are mostly orthogonal to testing. "Without solid unit tests backing you, activities like removing "obsolete" methods or renaming classes/modules turn into nightmare with duck typed languages." This is a nightmare regardless of typing. If you remove a method that is still used somewhere, you've broken something, and you may not spot it until after it ships to customers. It doesn't matter whether you have type checks or not. A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). Testing does resolve this problem--but it's not a problem specific to dynamic languages. If you get a warm fuzzy feeling from type checking from your compiler, then by all means, enjoy it. But there are tools for most mature dynamic languages (Perl and Python for example) that will do that checking without having to write tests manually. But, having never found type errors to be a problem in my Perl or Python code, I've never used them. Some problem sets are more prone to type mismatch bugs than others, and I guess my areas of interest are among the ones that are rarely effected.
- jey 19y ago
  A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). How is it not related to the compile-time name resolution and type checking? In a compiled typed language, you would get a compile or link error if the symbol is not found. I regularly write and refactor C++ by inducing compile or link errors to identify the spots in the code where a specific method is called from.
  - SwellJoe 19y ago
    "How is it not related to the compile-time name resolution and type checking?" Please re-read, carefully. I said that compiled and strongly typed are two orthogonal language characteristics, and that each of those characteristics solves one set of problems (while introducing some of its own). I specifically said exactly what you've said about compiled languages identifying missing methods. But it's not because it is a strongly typed language, it's because it is compiled. What's so bad about having a little clarity in our use of terms and concepts?

by tx 19y ago

richcollins 19y ago

We didn't write tests for our last startup and we never had too many problems with bugs. We do write tests for this one and we don't have too many problems with bugs. Tests take almost as much time to develop as the features do. I just wonder if it is worth the time and if other people with startups write automated tests.

jsjenkins168 19y ago
I'd say try to plan for how much you will need to scale your code, and also how many others will be working on your code. As your code gets larger, and as you start to have others working on it (who could break it), unit tests become more important. If you dont foresee either of these happening, then the time investment for tests may not be worth it..
tx 19y ago
No difference? That's pretty impressive. I wish I was able to look at your process. Either your engineers are extremely smart and anal about their practicies or your domain is very simplistic (ta-da lists). At my previous start up we had unit tests run on the entire system automatically after every check-in (with CruiseControl) and whenever someone broke a test suite, everybody got an email with name of the offender and diffs of his code against the trunk. We also had a "beer rule" about violatros gettings drinks for everyone, to make the process a bit more exciting.
- richcollins 19y ago
  Facebook doesn't have an automated test suite. I wouldn't call that a simplistic app.
  - immad 19y ago
    really?! I would be shocked if they dont have at least automated testing on their most critical systems. Whats the source of that info?
    - richcollins 19y ago
      we asked Mark Zuckerberg at Startup School
jimbokun 19y ago
Wil Shipley on unit tests: http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html http://wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html I think what he's saying is unit tests don't add much if you are doing UI type development. It is hard to write unit tests for UIs (web or GUI), so if most of your code is UI code, don't bother. However, if you are writing a library that will be used by a lot of coders, unit tests are probably indispensable. Otherwise, you would never be able to make even simple architecture or design changes (refactoring).

SwellJoe 19y ago

"Without automatic testing dynamic languages are not very productive because they do not catch type mismatch errors during compilation time (there isn't one). With statically typed languages you get a lot of tiny issues taken care of once you hit magic "compile" button and compiler does some basic sanity checks." You're just exhibiting a basic dislike of dynamic languages. Type mismatch errors are mostly orthogonal to testing. "Without solid unit tests backing you, activities like removing "obsolete" methods or renaming classes/modules turn into nightmare with duck typed languages." This is a nightmare regardless of typing. If you remove a method that is still used somewhere, you've broken something, and you may not spot it until after it ships to customers. It doesn't matter whether you have type checks or not. A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). Testing does resolve this problem--but it's not a problem specific to dynamic languages. If you get a warm fuzzy feeling from type checking from your compiler, then by all means, enjoy it. But there are tools for most mature dynamic languages (Perl and Python for example) that will do that checking without having to write tests manually. But, having never found type errors to be a problem in my Perl or Python code, I've never used them. Some problem sets are more prone to type mismatch bugs than others, and I guess my areas of interest are among the ones that are rarely effected.

jey 19y ago
A compiled language that links in those classes and methods at compile time does resolve this issue, but it's not related to types (and you have to wait on the bloody thing to compile every time you change one character in the file). How is it not related to the compile-time name resolution and type checking? In a compiled typed language, you would get a compile or link error if the symbol is not found. I regularly write and refactor C++ by inducing compile or link errors to identify the spots in the code where a specific method is called from.
- SwellJoe 19y ago
  "How is it not related to the compile-time name resolution and type checking?" Please re-read, carefully. I said that compiled and strongly typed are two orthogonal language characteristics, and that each of those characteristics solves one set of problems (while introducing some of its own). I specifically said exactly what you've said about compiled languages identifying missing methods. But it's not because it is a strongly typed language, it's because it is compiled. What's so bad about having a little clarity in our use of terms and concepts?