5 ms·

> I started writing tests in Rust as I would in any other language but found that I was writing tests couldn’t fail. This is a common refrain in C++ testing: i

> I started writing tests in Rust as I would in any other language but found that I was writing tests couldn’t fail. This is a common refrain in C++ testing: if it compiles then it's probably correct. > Rust has accounted for so many errors that many common test cases become irrelevant In practice, if you think this way I think it's a sign that you aren't testing the right things in those other languages. You should be testing business logic, not language stuff. If you look at your test code and think "I would test this in JavaScript, but I don't need to do that in Rust" then just delete the test.

adastra22 3y ago
> This is a common refrain in C++ testing: if it compiles then it's probably correct. I’ve heard this in Haskell and in Rust. I’ve never heard it applied to C++…
- ModernMech 3y ago
  I think they meant Rust? Rust definitely has that property to an extent; C++ is so far from it it’s not even funny.
- jeremyjh 3y ago
  I’ve definitely experienced it in Haskell and Rust. I can believe some C++ could be that way, but I’ve never experienced it, but then again those projects didn’t have useful tests either. I think with C++ a lot of this depends on domain and the quality of the code and libraries.
- xhainingx 3y ago
  It's truer in C++ than java or similar languages ime since java relies more on exceptions, but it's certainly not as true as Haskell or rust
  - Skunkleton 3y ago
    Is it true enough in c++ to be useful though?
  - Capricorn2481 3y ago
    No it isn't lol. C++ compiles all the time with bugs.
- camkego 3y ago
  That used to be a joke at many places I worked at with large C/Cpp code bases. Always said tongue in cheek.
- PoignardAzur 3y ago
  I've experienced it a bit in C++, especially after coming back from JS. But not to the degree of Rust.
Sharlin 3y ago
A null pointer exception is a bug that breaks business logic. There's no "business logic instead of language stuff" because the language stuff is the foundation that business logic rests on. If you don't test against failure modes, what's even the point in testing?
- maxbond 3y ago
  To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.
  - tialaramex 3y ago
    To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.
    - pornel 3y ago
      And even for raw pointers you can use NonNull<T>.
    - deleted 3y ago
      [deleted]
  - benibela 3y ago
    Still someone might call unwrap on an Option and then run into some kind of null pointer exception
    - 3y ago
tialaramex 3y ago
There is surely something wonderful about the kind of C++ programmer who figures that, since their unusable broken garbage compiled it's probably correct. Remember unlike most languages you'd be familiar with C++ has IFNDR, which has been jokingly referred to as "False positives for the question: Is this a C++ program?". A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. Is it a working executable? Could be. Or maybe it's exactly like a working executable except it explodes catastrophically on Fridays. No way to know. † The ISO standard does identify these cases, but they're so vague that it's hard to pin down everything which is covered. My guess is that all or most non-trivial C++ software is actually IFNDR these days. Just say No to the entire language.
- lmm 3y ago
  > A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. It's not quite that bad - a conforming C++ compiler is permitted to error out and not compile the program. It just doesn't have to.
  - tialaramex 3y ago
    Many of the cases of IFNDR are semantic constraints, especially in C++ 20 and beyond. As a result of being semantic constraints it's generally impossible to diagnose this with no false positives. The ISO standard forbids such false positives so...
    - lmm 3y ago
      Can you give a more concrete example of the kind of thing you're talking about? Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint, and any sane implementor would do that. (Not that any sane person would ever write a C++ compiler...)

adastra22 3y ago

> This is a common refrain in C++ testing: if it compiles then it's probably correct. I’ve heard this in Haskell and in Rust. I’ve never heard it applied to C++…

ModernMech 3y ago
I think they meant Rust? Rust definitely has that property to an extent; C++ is so far from it it’s not even funny.
jeremyjh 3y ago
I’ve definitely experienced it in Haskell and Rust. I can believe some C++ could be that way, but I’ve never experienced it, but then again those projects didn’t have useful tests either. I think with C++ a lot of this depends on domain and the quality of the code and libraries.
xhainingx 3y ago
It's truer in C++ than java or similar languages ime since java relies more on exceptions, but it's certainly not as true as Haskell or rust
- Skunkleton 3y ago
  Is it true enough in c++ to be useful though?
- Capricorn2481 3y ago
  No it isn't lol. C++ compiles all the time with bugs.
camkego 3y ago
That used to be a joke at many places I worked at with large C/Cpp code bases. Always said tongue in cheek.
PoignardAzur 3y ago
I've experienced it a bit in C++, especially after coming back from JS. But not to the degree of Rust.

Sharlin 3y ago

A null pointer exception is a bug that breaks business logic. There's no "business logic instead of language stuff" because the language stuff is the foundation that business logic rests on. If you don't test against failure modes, what's even the point in testing?

maxbond 3y ago
To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.
- tialaramex 3y ago
  To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.
  - pornel 3y ago
    And even for raw pointers you can use NonNull<T>.
  - deleted 3y ago
    [deleted]
- benibela 3y ago
  Still someone might call unwrap on an Option and then run into some kind of null pointer exception
  - 3y ago

tialaramex 3y ago

There is surely something wonderful about the kind of C++ programmer who figures that, since their unusable broken garbage compiled it's probably correct. Remember unlike most languages you'd be familiar with C++ has IFNDR, which has been jokingly referred to as "False positives for the question: Is this a C++ program?". A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. Is it a working executable? Could be. Or maybe it's exactly like a working executable except it explodes catastrophically on Fridays. No way to know. † The ISO standard does identify these cases, but they're so vague that it's hard to pin down everything which is covered. My guess is that all or most non-trivial C++ software is actually IFNDR these days. Just say No to the entire language.

lmm 3y ago
> A conforming C++ compiler is forbidden from telling you in some† unknown number of cases that it suspects what you've written is nonsense, it just has to press on and output... something. It's not quite that bad - a conforming C++ compiler is permitted to error out and not compile the program. It just doesn't have to.
- tialaramex 3y ago
  Many of the cases of IFNDR are semantic constraints, especially in C++ 20 and beyond. As a result of being semantic constraints it's generally impossible to diagnose this with no false positives. The ISO standard forbids such false positives so...
  - lmm 3y ago
    Can you give a more concrete example of the kind of thing you're talking about? Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint, and any sane implementor would do that. (Not that any sane person would ever write a C++ compiler...)