3 ms·

> Which you say is to be avoided, and that there are better ways, without sharing what those better ways are... That's because it would better fit in a book th

> Which you say is to be avoided, and that there are better ways, without sharing what those better ways are... That's because it would better fit in a book than an HN comment, not because I don't want to answer. Basically the gist is to write "obviously correct" code that doesn't need to be tested, along with an architecture that lends itself to being testable without mocks. Most people tend to write an interface and then inject a concrete type that could also be a mock. I've seen tests written this way that need to mock out 20-60 things just to test the one thing they want to test. In most web frameworks I've worked with, this is mostly unavoidable as most frameworks provide dependency injection that is natural to mock. If you aren't using a framework that has an opinion on how things should work, mocks can be avoided completely through different techniques, such as test harnesses, replacing dependencies with alternative implementations (such as in-memory queues instead of cloud services, sqlite instead of heavy databases, etc), etc. Sometimes you don't have any choice but to not use mocks, for example, distributed systems usually avoid mocks for certain kinds of tests because they simply can't be emulated very well -- either due to latency, network partitioning, or network failures that are just too numerous to mock out (similar to the disk issue I was referring too earlier). You don't know if a node is down, or the cable got cut, and need to behave appropriately to avoid split-brain scenarios. In these cases, test harnesses that can emulate specific scenarios are much better.

9rx 2y ago
> Basically the gist is to write "obviously correct" code that doesn't need to be tested I don't see how that follows. The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. The only 'correctness' a test proves is that the documentation is true. Which is still incredibly useful, as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation (e.g. plain text files, Word documents, HTML, etc.) that quickly become out of date, but is not a statement about the code itself. > such as test harnesses, replacing dependencies with alternative implementations (such as in-memory queues instead of cloud services, sqlite instead of heavy databases, etc), etc. These are all mocks, ultimately. Some desperately try to give them different names, but it is all the same at the end of the day.
- withinboredom 2y ago
  > The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. Hmm. I've never seen tests with that goal in mind, except for behavioral tests that test the acceptance critera. > as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation [...] that quickly become out of date I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen. When I open PRs to open source software, I always include a PR to the docs if it changes anything. At work, updating the docs is part of the default acceptance criteria and is usually the thing we do before writing any code, and goes through a PR process just like the code. But, we service enterprise customers, so we aren't going to be giving them code or tests to understand how to use our product. > These are all mocks, ultimately. This is a software field and there are specific words with specific meaning; trying to shoehorn things that aren't those things to generalize a meaning is acceptable when teaching. It isn't acceptable when working on those things. In other words, I would accept this if trying to explain the concept to a junior engineer, but not from a senior engineer to a senior engineer. > it is all the same at the end of the day. No, not at all.
  - 9rx 2y ago
    > I've never seen tests with that goal in mind Then you've never seen a test, I guess. That is the only goal they can serve, fundamentally. > I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen. Mistakes are guaranteed to happen given enough output/time. No matter how hard you try, you are going to make a mistake at some point. It is the human condition. In the olden days one might use a proofreader to try and catch the mistakes, but with the advent of testing a computer can do the "proofreading" automatically, leaving the human effort to be pointless. Maybe in the age of LLMs we can go back to writing documentation in "natural" language while still using machines to do the validation work, but then again if you write code you probably would prefer to read code. I know I would! The best language is the one you are already using. Having to read code documentation in English is a horrible user experience. > This is a software field and there are specific words with specific meaning Sure, but in this case you won't find any real difference in meaning across the vast array of words we try to use here. The desperate attempts to try and find new words is to broach silly soundbites like "mocks are a code smell", so that one can say "I'm not mocking, I'm flabbergasting!", even though it is the same thing...

9rx 2y ago

> Basically the gist is to write "obviously correct" code that doesn't need to be tested I don't see how that follows. The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. The only 'correctness' a test proves is that the documentation is true. Which is still incredibly useful, as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation (e.g. plain text files, Word documents, HTML, etc.) that quickly become out of date, but is not a statement about the code itself. > such as test harnesses, replacing dependencies with alternative implementations (such as in-memory queues instead of cloud services, sqlite instead of heavy databases, etc), etc. These are all mocks, ultimately. Some desperately try to give them different names, but it is all the same at the end of the day.

withinboredom 2y ago
> The purpose of testing is to document the code for the understanding of future developers, not to prove correctness. Hmm. I've never seen tests with that goal in mind, except for behavioral tests that test the acceptance critera. > as I am sure you are painfully aware if you have ever dealt with legacy forms of documentation [...] that quickly become out of date I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen. When I open PRs to open source software, I always include a PR to the docs if it changes anything. At work, updating the docs is part of the default acceptance criteria and is usually the thing we do before writing any code, and goes through a PR process just like the code. But, we service enterprise customers, so we aren't going to be giving them code or tests to understand how to use our product. > These are all mocks, ultimately. This is a software field and there are specific words with specific meaning; trying to shoehorn things that aren't those things to generalize a meaning is acceptable when teaching. It isn't acceptable when working on those things. In other words, I would accept this if trying to explain the concept to a junior engineer, but not from a senior engineer to a senior engineer. > it is all the same at the end of the day. No, not at all.
- 9rx 2y ago
  > I've never seen tests with that goal in mind Then you've never seen a test, I guess. That is the only goal they can serve, fundamentally. > I have, but allowing that to happen is a culture-issue, not something that is guaranteed to happen. Mistakes are guaranteed to happen given enough output/time. No matter how hard you try, you are going to make a mistake at some point. It is the human condition. In the olden days one might use a proofreader to try and catch the mistakes, but with the advent of testing a computer can do the "proofreading" automatically, leaving the human effort to be pointless. Maybe in the age of LLMs we can go back to writing documentation in "natural" language while still using machines to do the validation work, but then again if you write code you probably would prefer to read code. I know I would! The best language is the one you are already using. Having to read code documentation in English is a horrible user experience. > This is a software field and there are specific words with specific meaning Sure, but in this case you won't find any real difference in meaning across the vast array of words we try to use here. The desperate attempts to try and find new words is to broach silly soundbites like "mocks are a code smell", so that one can say "I'm not mocking, I'm flabbergasting!", even though it is the same thing...