9 ms·

I'm not sure how they're mutually exclusive. Also TDD is more of a _design_ technique than a testing technique. I've worked in languages with extremely expressi

by quii 6y ago

I'm not sure how they're mutually exclusive. Also TDD is more of a _design_ technique than a testing technique. I've worked in languages with extremely expressive typesystems (like Scala) and I still practiced TDD

fhunt 6y ago
> I'm not sure how they're mutually exclusive. Where did I say that? I just meant, and my apologies for not being clear, focus should be types, ofc you still need tests. But not as many as a decade ago and more important, people must drop this dogma that tests are the key to everything. There are not and the more tests a codebase has the worse its quality and maintainability. > I still practiced TDD You can do this ofc but my experience differs: Once you have an excellent type system, both in terms of language features and tool chain eg editor, you can literally code for days without running even the compiler once. This is pure flow and very much the opposite of TDD. But the entry barrier of is much higher than TDD. Don't get me wrong, you still need tests but TDD?? IDK, this feels like trial-and-error-coding from 2010. I mean if we still used all Ruby, yes tests and TDD everywhere but the environment has changed.
- eterps 6y ago
  > both in terms of language features and tool chain What would you give as examples for language features and toolchains that enable the workflow you are suggesting?
  - fhunt 6y ago
    TS has by far the most advanced compile-time type system followed by Rust. TS has the best and most responsive editor support (tsserver). I know that Rust's is much slower but IDK much more than that. Re ecosystem and build system: TS' build system is not trivial but it's very flexible and has a bigger ecosystem.
    - valenterry 6y ago
      Idris and F* have a much much more advanced type system, compared to Typescript and Rust. But even if you deem these languages not "mainstream" enough, there is still e.g. Scala which has a typesystem that beats the one of Rust by far and also the one of Typescript, minus certain special cases where Typescript is really nice. It is great to see though that even frontend-mainstream languages like Typescript start to get proper support for type-systems (especially considering that they had to do it on top of Javascript). Very excited to see where we go with languages and I agree with you that TDD should now by default mean "type driven development". :)
  - deleted 6y ago
    [deleted]
- mseepgood 6y ago
  Let's say you have implemented a function that sorts a list in Haskell, which has a relatively strong type system. How do you make sure that it sorts the list and does not reverse it instead, how do you know that your job is done?
  - a_imho 6y ago
    This is not the same problem AFAIU. You don't know whether your tests encode the correct specification either, but you must run them first to find out whether they pass, but with (dependent) types you can have the sorted list property encoded in compile time, but still can't be sure whether it is correct.
    - _fz 6y ago
      I recently implemented Conway's Game of Life in Agda. I still had to write "test cases" to get the whole thing right: https://github.com/fzipp/agda-life/blob/18dda7f45541d2e8f47c351d72a20a25d3bfb4be/GameOfLife.agda#L95 https://github.com/fzipp/agda-life/blob/18dda7f45541d2e8f47c... Sure, they are validated at compile time because they are propositions as types, but in the end they are still basically test cases: expected output for a given input, and the compiler is the test runner. I don't know how to encode the full "Game of Life" property as dependent types, I am still an Agda newbie.
      - valenterry 6y ago
        In this context, I think we should not call them "tests" to not mix them up with "runtime tests". Even though they are indeed tests in a sense
        _fz 6y ago
        Sure, I don't know what the correct term is. But I personally did not really gain anything from the type system that helped me get the logic of the program right. Whether a Turing complete type system "runs" my assertions at compile time, or a test runner does it on save does not make a difference to me. Actually, I could measure the compile time for this simple one-page program in seconds, while the Go tools compile and test a Game of Life implementation in a fraction of a second.
- qsort 6y ago
  > There are not and the more tests a codebase has the worse its quality and maintainability. I'm fully sold that types are important, personally I would object to starting any mid- to large-scale project in a dynamically typed language, but this doesn't ring true at all. When you're writing and refactoring code that uses complex logic, you aren't necessarily able to encode that logic in the type system. Carefully written tests allow you to confidently edit the code without worrying that you might have broken something in the process. If anything, strong type systems allow you to change the way you write and structure tests (more towards property-based testing as opposed to dumb test cases), but I wouldn't advocate completely doing away with them.
  - fhunt 6y ago
    > but I wouldn't advocate completely doing away with them. didn't say this > Carefully written tests allow you to confidently edit the code without worrying that you might have broken something in the process. yes true but again you get this with typed code without any tests for 80% of the code as well, look, it's about the quantity and what you are going to test. with types you need way less unit tests (some like ben awad say none!) but still integration tests. still doing tests like crazy and like it's 2010 defocusses your devs and makes refactoring much more tedious, change a small thing and rewrite twenty unnecessary tests from a too ambitious test warrior who didn't understand types. this creates a notion where codebases get stale and untouched for years. nobody likes to refactor test code bc it's an unattached piece of code which complicates things more than it helps, it rarely feels like a true spec but rather like some random code and the next one wonders why his predecessor wrote this test at all. this is so the past idk why people are worshipping this. Write tests where types don't help anymore (integration tests!) and things are crucial, otherwise focus on the core logic. I have rather devs who write excellent typed code with just very few integration tests than somebody who drives nuts and goes down the full rabbit hole writing 10x more test code nobody asked for than actual code paired with such blog posts like from OP on top, they've missed the boat.
    - qsort 6y ago
      > doing tests like crazy and like it's 2010 defocusses your devs and makes refactoring much more tedious I'm fully sold on this as well, but: > it's about the quantity and what you are going to test I'd say it's more about how you're going to test. What is covered by the type system should be handled by the type system, that's an absolute no brainer, using tests, or even worse, comments or conventions as opposed to types is just objectively wrong. Because you can now be confident that trivial mistakes will be caught by the compiler, you can have actually meaningful tests, like "this property is satisfied", as opposed to "this object has this field set to this string". So I wouldn't say "write less tests", I'd say "since types free you from the burden of testing stupid things, write better tests".

by quii 6y ago

fhunt 6y ago

> I'm not sure how they're mutually exclusive. Where did I say that? I just meant, and my apologies for not being clear, focus should be types, ofc you still need tests. But not as many as a decade ago and more important, people must drop this dogma that tests are the key to everything. There are not and the more tests a codebase has the worse its quality and maintainability. > I still practiced TDD You can do this ofc but my experience differs: Once you have an excellent type system, both in terms of language features and tool chain eg editor, you can literally code for days without running even the compiler once. This is pure flow and very much the opposite of TDD. But the entry barrier of is much higher than TDD. Don't get me wrong, you still need tests but TDD?? IDK, this feels like trial-and-error-coding from 2010. I mean if we still used all Ruby, yes tests and TDD everywhere but the environment has changed.

eterps 6y ago
> both in terms of language features and tool chain What would you give as examples for language features and toolchains that enable the workflow you are suggesting?
- fhunt 6y ago
  TS has by far the most advanced compile-time type system followed by Rust. TS has the best and most responsive editor support (tsserver). I know that Rust's is much slower but IDK much more than that. Re ecosystem and build system: TS' build system is not trivial but it's very flexible and has a bigger ecosystem.
  - valenterry 6y ago
    Idris and F* have a much much more advanced type system, compared to Typescript and Rust. But even if you deem these languages not "mainstream" enough, there is still e.g. Scala which has a typesystem that beats the one of Rust by far and also the one of Typescript, minus certain special cases where Typescript is really nice. It is great to see though that even frontend-mainstream languages like Typescript start to get proper support for type-systems (especially considering that they had to do it on top of Javascript). Very excited to see where we go with languages and I agree with you that TDD should now by default mean "type driven development". :)
- deleted 6y ago
  [deleted]
mseepgood 6y ago
Let's say you have implemented a function that sorts a list in Haskell, which has a relatively strong type system. How do you make sure that it sorts the list and does not reverse it instead, how do you know that your job is done?
- a_imho 6y ago
  This is not the same problem AFAIU. You don't know whether your tests encode the correct specification either, but you must run them first to find out whether they pass, but with (dependent) types you can have the sorted list property encoded in compile time, but still can't be sure whether it is correct.
  - _fz 6y ago
    I recently implemented Conway's Game of Life in Agda. I still had to write "test cases" to get the whole thing right: https://github.com/fzipp/agda-life/blob/18dda7f45541d2e8f47c351d72a20a25d3bfb4be/GameOfLife.agda#L95 https://github.com/fzipp/agda-life/blob/18dda7f45541d2e8f47c... Sure, they are validated at compile time because they are propositions as types, but in the end they are still basically test cases: expected output for a given input, and the compiler is the test runner. I don't know how to encode the full "Game of Life" property as dependent types, I am still an Agda newbie.
    - valenterry 6y ago
      In this context, I think we should not call them "tests" to not mix them up with "runtime tests". Even though they are indeed tests in a sense
      - _fz 6y ago
        Sure, I don't know what the correct term is. But I personally did not really gain anything from the type system that helped me get the logic of the program right. Whether a Turing complete type system "runs" my assertions at compile time, or a test runner does it on save does not make a difference to me. Actually, I could measure the compile time for this simple one-page program in seconds, while the Go tools compile and test a Game of Life implementation in a fraction of a second.
qsort 6y ago
> There are not and the more tests a codebase has the worse its quality and maintainability. I'm fully sold that types are important, personally I would object to starting any mid- to large-scale project in a dynamically typed language, but this doesn't ring true at all. When you're writing and refactoring code that uses complex logic, you aren't necessarily able to encode that logic in the type system. Carefully written tests allow you to confidently edit the code without worrying that you might have broken something in the process. If anything, strong type systems allow you to change the way you write and structure tests (more towards property-based testing as opposed to dumb test cases), but I wouldn't advocate completely doing away with them.
- fhunt 6y ago
  > but I wouldn't advocate completely doing away with them. didn't say this > Carefully written tests allow you to confidently edit the code without worrying that you might have broken something in the process. yes true but again you get this with typed code without any tests for 80% of the code as well, look, it's about the quantity and what you are going to test. with types you need way less unit tests (some like ben awad say none!) but still integration tests. still doing tests like crazy and like it's 2010 defocusses your devs and makes refactoring much more tedious, change a small thing and rewrite twenty unnecessary tests from a too ambitious test warrior who didn't understand types. this creates a notion where codebases get stale and untouched for years. nobody likes to refactor test code bc it's an unattached piece of code which complicates things more than it helps, it rarely feels like a true spec but rather like some random code and the next one wonders why his predecessor wrote this test at all. this is so the past idk why people are worshipping this. Write tests where types don't help anymore (integration tests!) and things are crucial, otherwise focus on the core logic. I have rather devs who write excellent typed code with just very few integration tests than somebody who drives nuts and goes down the full rabbit hole writing 10x more test code nobody asked for than actual code paired with such blog posts like from OP on top, they've missed the boat.
  - qsort 6y ago
    > doing tests like crazy and like it's 2010 defocusses your devs and makes refactoring much more tedious I'm fully sold on this as well, but: > it's about the quantity and what you are going to test I'd say it's more about how you're going to test. What is covered by the type system should be handled by the type system, that's an absolute no brainer, using tests, or even worse, comments or conventions as opposed to types is just objectively wrong. Because you can now be confident that trivial mistakes will be caught by the compiler, you can have actually meaningful tests, like "this property is satisfied", as opposed to "this object has this field set to this string". So I wouldn't say "write less tests", I'd say "since types free you from the burden of testing stupid things, write better tests".