3 ms·

> unittests are a first class keyword in D, which makes writing tests easy, therefore people actually write tests. This feature is maybe a 100 line diff to most

> unittests are a first class keyword in D, which makes writing tests easy, therefore people actually write tests. This feature is maybe a 100 line diff to most compilers, and yet basically only D exploits that fact. I'm interested in how this makes the testing experience much easier. In most of the modern languages I've used setting up tests is a similar amount of words (Elixir, Rust) or one-time fifteen minute task (Kotlin). In all of those there are options for tightly-integrated testing environments, but they're not (entirely) literally in the compiler so you can make your own competing one.

mhh__ 5y ago
It's not about ease at scale but rather friction locally. If you can enforce tests from the top down then all you've saved is some characters, but if you can make testing easier from day 0 people write more tests and get better coverage. There is no setup. Also, the unit tests the compiler implements are just special functions, the actually running of the tests can be as dumb or as complicated as you want (Which D makes trivial because of the reflection capabilities). One thing that I don't think you can do with other approaches, is actually have a unit test inside a template, so you know it gets tested for all parameters that it is instantiated with.
- iudqnolq 5y ago
  > if you can make testing easier from day 0 people write more tests and get better coverage. I could see it helping move from 0 to nonzero, but most languages have a constant overhead in test setup. If one person starts testing, or you have a standard template, the setup is done. > Also, the unit tests the compiler implements are just special functions, the actually running of the tests can be as dumb or as complicated as you want (Which D makes trivial because of the reflection capabilities). Nice! That's basically the approach rust takes (annotate tests with #[test], either use the default test runner that generates a main fn that runs them or bring your own). > One thing that I don't think you can do with other approaches, is actually have a unit test inside a template, so you know it gets tested for all parameters that it is instantiated with. That does sound useful. You definitely can't do that in any language I've used. If you need that you definitely have buggy abstractions, but then we always do.
  - mhh__ 5y ago
    > If you need that you definitely have buggy abstractions, but then we always do. Not quite, or at least not always. D embraces something called design by introspection - that basically means adapting behaviour at compile time based on what a parameter can do rather than what a parameter should do (in the case of a template). This allows you to write extremely expressive (and fast) code, however you do at this point need to test at a more granular level. https://www.youtube.com/watch?v=HdzwvY8Mo-w https://www.youtube.com/watch?v=HdzwvY8Mo-w
  - WalterBright 5y ago
    > the approach rust takes Quite a lot of D's innovative features have become standard in other languages as well. For example, there was an overlooked feature in Ada that I always liked: int i = 1_000_000; int phone = 214_222_1234; I.e. _ can be inserted in numeric literals to make them easier to read. After D did popularized this, this feature started appearing in other languages. Other such features include ranges, and staticif. Even static assert.
    - mhh__ 5y ago
      > staticif Or not appearing in the case of that one. Slightly before my time but I read the C++ papers considering it and they are a bit strange.
      - WalterBright 5y ago
        staticif has recently appeared in C++, just under a different name.
        mhh__ 5y ago
        The solution C++ has - as Andrei says - is not the same thing as static if because it introduces a scope
        WalterBright 5y ago
WalterBright 5y ago
Here's what happens (the same thing happened with Ddoc, the documentation generator build in to the compiler). Before Ddoc, there were documentation generators like DOxygen, a third party tool. Doxygen was a fine documentation generator, with lots of great features. The trouble was, it was a third party tool: 1. There were other documentation generators, all different. 2. People would install D, and not have a documentation generator. They'd have to do research, pick one, and install it. 3. The third party tool may not work that well with D. 4. The third party tool may be out of sync with the version of D that the user is doing. 5. The third party tool always comes with a large and intimidating manual. The end result was, maybe 1% of D users used a documentation generator. 10% wrote documentation as a separate file. 89% just wrote zero documentation at all. Even worse, the 10% documentation rarely matched what the function actually did. In fact, sometimes it was unrecognizable. This was the state of, for example, the D runtime library documentation. All of it was either totally wrong, out of date, or missing entirely. Enter Ddoc. Yes, Ddoc is inferior to DOxygen. But every D user now has a documentation already installed, and a perfect match for the version of D they have. Now writing documentation becomes trivial, as Ddoc can read the function headers. When one modifies the function, it's trivial to fix the documentation, as it's right there. When submitting a pull request, the reviewer goes "where's the documentation". The result was a night and day difference. Suddenly the Phobos documentation was all there, and accurate. The same effect happened with builtin unittests. Sure, D's builtin unittest framework isn't as good as advanced third party testing frameworks. But it's always there, and always works, and the difference in results is stunning. Take a look at the Phobos source code - half of it is unittests.

mhh__ 5y ago

It's not about ease at scale but rather friction locally. If you can enforce tests from the top down then all you've saved is some characters, but if you can make testing easier from day 0 people write more tests and get better coverage. There is no setup. Also, the unit tests the compiler implements are just special functions, the actually running of the tests can be as dumb or as complicated as you want (Which D makes trivial because of the reflection capabilities). One thing that I don't think you can do with other approaches, is actually have a unit test inside a template, so you know it gets tested for all parameters that it is instantiated with.

iudqnolq 5y ago
> if you can make testing easier from day 0 people write more tests and get better coverage. I could see it helping move from 0 to nonzero, but most languages have a constant overhead in test setup. If one person starts testing, or you have a standard template, the setup is done. > Also, the unit tests the compiler implements are just special functions, the actually running of the tests can be as dumb or as complicated as you want (Which D makes trivial because of the reflection capabilities). Nice! That's basically the approach rust takes (annotate tests with #[test], either use the default test runner that generates a main fn that runs them or bring your own). > One thing that I don't think you can do with other approaches, is actually have a unit test inside a template, so you know it gets tested for all parameters that it is instantiated with. That does sound useful. You definitely can't do that in any language I've used. If you need that you definitely have buggy abstractions, but then we always do.
- mhh__ 5y ago
  > If you need that you definitely have buggy abstractions, but then we always do. Not quite, or at least not always. D embraces something called design by introspection - that basically means adapting behaviour at compile time based on what a parameter can do rather than what a parameter should do (in the case of a template). This allows you to write extremely expressive (and fast) code, however you do at this point need to test at a more granular level. https://www.youtube.com/watch?v=HdzwvY8Mo-w https://www.youtube.com/watch?v=HdzwvY8Mo-w
- WalterBright 5y ago
  > the approach rust takes Quite a lot of D's innovative features have become standard in other languages as well. For example, there was an overlooked feature in Ada that I always liked: int i = 1_000_000; int phone = 214_222_1234; I.e. _ can be inserted in numeric literals to make them easier to read. After D did popularized this, this feature started appearing in other languages. Other such features include ranges, and staticif. Even static assert.
  - mhh__ 5y ago
    > staticif Or not appearing in the case of that one. Slightly before my time but I read the C++ papers considering it and they are a bit strange.
    - WalterBright 5y ago
      staticif has recently appeared in C++, just under a different name.
      - mhh__ 5y ago
        The solution C++ has - as Andrei says - is not the same thing as static if because it introduces a scope
        WalterBright 5y ago

WalterBright 5y ago

Here's what happens (the same thing happened with Ddoc, the documentation generator build in to the compiler). Before Ddoc, there were documentation generators like DOxygen, a third party tool. Doxygen was a fine documentation generator, with lots of great features. The trouble was, it was a third party tool: 1. There were other documentation generators, all different. 2. People would install D, and not have a documentation generator. They'd have to do research, pick one, and install it. 3. The third party tool may not work that well with D. 4. The third party tool may be out of sync with the version of D that the user is doing. 5. The third party tool always comes with a large and intimidating manual. The end result was, maybe 1% of D users used a documentation generator. 10% wrote documentation as a separate file. 89% just wrote zero documentation at all. Even worse, the 10% documentation rarely matched what the function actually did. In fact, sometimes it was unrecognizable. This was the state of, for example, the D runtime library documentation. All of it was either totally wrong, out of date, or missing entirely. Enter Ddoc. Yes, Ddoc is inferior to DOxygen. But every D user now has a documentation already installed, and a perfect match for the version of D they have. Now writing documentation becomes trivial, as Ddoc can read the function headers. When one modifies the function, it's trivial to fix the documentation, as it's right there. When submitting a pull request, the reviewer goes "where's the documentation". The result was a night and day difference. Suddenly the Phobos documentation was all there, and accurate. The same effect happened with builtin unittests. Sure, D's builtin unittest framework isn't as good as advanced third party testing frameworks. But it's always there, and always works, and the difference in results is stunning. Take a look at the Phobos source code - half of it is unittests.