5 ms·

Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away

Compile time unit tests are as bad of an idea as "unused import/variable/result" errors (rather than warnings). They're "nanny features" that take control away from the developer and inevitably cause you to jump through bureaucratic hoops just to get your work done. These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds (which are what 99% of your builds are). It's like saying "You can't use the table saw until you put the drill away!"

omoikane 2y ago
Maybe these compile time tests are more like `static_assert`, which is valuable for catching incompatible uses of library functions. Pretty good idea in my opinion.
- kstenerud 2y ago
  Sure, enforcing invariants is a good thing to do right off the bat. But not "does this code do what it says on the tin?" kinds of tests. Those are better run gradually, at the (current) developer's behest (and most certainly, not blocking compilation).
- tczMUFlmoNk 2y ago
  The article is literally talking about `_Static_assert`, yes. It's used in the code examples and described in the text.
chii 2y ago
> These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds i tend to disagree. If you tried to express some thought but the compile time tests tells you you're wrong, you might actually just have an incomplete thought, or have not thought through all of the consequences of said expression. It's basically what type-checking is in haskell - you cannot compile a program that does not type-check correctly. This forces you as a programmer, to always, and only, express complete thoughts. Incomplete, or contradictory thoughts cannot be expressed. This should, in theory, lead to programs that are more well thought out. It also makes the program harder to write, because it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care.
- kstenerud 2y ago
  > it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care. And this is precisely why I disagree with forcing it upon the developer at every stage of development. Generally, while in the thick of things, I just want to get things working with one part, not worry about what other parts this breaks (yet). But the pedantic "you have to fix this first" enforcement breaks my concentration because now I have to split my attention to things I don't want to even be bothered with yet. I'll get to it, but I sure as hell don't want you telling me WHEN I should.
  - fishstock25 2y ago
    > because now I have to split my attention to things I don't want to even be bothered with yet. One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them. Is that the same as saying I don't want to have to write types either? Maybe. Types are like lightweight incomplete specs.
    - kstenerud 2y ago
      > One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them. Or perhaps the parts existed, were useful, did have tests, and now a new feature requires refactoring that temporarily breaks things before I finally bring the house in order again. But I don't want to throw out the tests because parts of them may still be useful. My point is, if the code is capable of being compiled and run, who is anyone to dictate that I shouldn't be allowed to run it (even broken) during my development cycle, just for some bureaucratic "I know better than you" reason? This is the problem I see all over - people peer out from their limited perspective, assume that they see enough, and then make excessively restrictive policy decisions about what we can and cannot do. It's hubristic and so very, very annoying to the rest of us, especially since they also have a tendency to double-down, and there seems to be no way of getting through to them.
  - marcosdumay 2y ago
deleted 2y ago
[deleted]

omoikane 2y ago

Maybe these compile time tests are more like `static_assert`, which is valuable for catching incompatible uses of library functions. Pretty good idea in my opinion.

kstenerud 2y ago
Sure, enforcing invariants is a good thing to do right off the bat. But not "does this code do what it says on the tin?" kinds of tests. Those are better run gradually, at the (current) developer's behest (and most certainly, not blocking compilation).
tczMUFlmoNk 2y ago
The article is literally talking about `_Static_assert`, yes. It's used in the code examples and described in the text.

chii 2y ago

> These kinds of build-failing tests are great for your "I think I'm finished now" build, but not for your "I'm in the middle of something" builds i tend to disagree. If you tried to express some thought but the compile time tests tells you you're wrong, you might actually just have an incomplete thought, or have not thought through all of the consequences of said expression. It's basically what type-checking is in haskell - you cannot compile a program that does not type-check correctly. This forces you as a programmer, to always, and only, express complete thoughts. Incomplete, or contradictory thoughts cannot be expressed. This should, in theory, lead to programs that are more well thought out. It also makes the program harder to write, because it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care.

kstenerud 2y ago
> it forces the programmer to discover corners of their program for which they "know" isn't valid but don't care. And this is precisely why I disagree with forcing it upon the developer at every stage of development. Generally, while in the thick of things, I just want to get things working with one part, not worry about what other parts this breaks (yet). But the pedantic "you have to fix this first" enforcement breaks my concentration because now I have to split my attention to things I don't want to even be bothered with yet. I'll get to it, but I sure as hell don't want you telling me WHEN I should.
- fishstock25 2y ago
  > because now I have to split my attention to things I don't want to even be bothered with yet. One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them. Is that the same as saying I don't want to have to write types either? Maybe. Types are like lightweight incomplete specs.
  - kstenerud 2y ago
    > One of the reasons could that you realize you don't need those parts, so it would have been a waste of time to write tests for them. Or perhaps the parts existed, were useful, did have tests, and now a new feature requires refactoring that temporarily breaks things before I finally bring the house in order again. But I don't want to throw out the tests because parts of them may still be useful. My point is, if the code is capable of being compiled and run, who is anyone to dictate that I shouldn't be allowed to run it (even broken) during my development cycle, just for some bureaucratic "I know better than you" reason? This is the problem I see all over - people peer out from their limited perspective, assume that they see enough, and then make excessively restrictive policy decisions about what we can and cannot do. It's hubristic and so very, very annoying to the rest of us, especially since they also have a tendency to double-down, and there seems to be no way of getting through to them.
- marcosdumay 2y ago

deleted 2y ago

[deleted]