> Definitely not hundreds. But yes, they need to be tested
Most likely hundreds. Each individual external service will easily have tens of conditions (a multitude of invalid input states, a multitude of malformed response payload states, a multitude of expected upstream error conditions, network interruption, port exhaustion, expired/invalid certificates, failed authentication/authorization, timeouts, etc., etc.) and when multiplied across them it won't be long before you have hundreds.
> Tests are not written to document behaviour, but to validate that your program does what it's supposed to do
A common misconception, but no. Tests would serve no purpose if you had no reason to document expected behaviour. Correct that tests also allow the machine to validate that what the documentation says is true, solving for the problems of the past where documentation and implementation would regularly fall out of sync. That is, indeed, the value proposition over writing the same information in Word instead.
Your documentation doesn't end there, of course, just as the documentation provided by a static type system is not the be all and end all of your documentation. But documentation it most certainly is.
> Existing testing practices all but enforce writing useless tests
The invented practices you have presented throughout the discussion no doubt lead to writing useless tests. It is, however, not clear why you hang on this invention of yours – outright ignoring what you are being given. Is it some kind of defence mechanism to protect the methods you have developed for yourself?
> Each individual external service will easily have tens of conditions
You will likely not propagate those to the end user, but log and return a single error for many of those cases
> A common misconception, but no.
A common misconception is that tests are documentation in any shape or form.
> Tests would serve no purpose if you had no reason to document expected behaviour.
You do not document behaviour with tests. You write the tests to make sure your app conforms to documented behaviour.
As documentation tests are useless because they are a collection of separate and disparate scenarios and cases lacking any context or continuity. If anyone ends up looking at tests for documentation on how your app or service behaves, I have bad news for you.
> Your documentation doesn't end there
Thts is literally the dead end of documentation. Well, the actual dead end is "code is documentation" and "types are documentation". Neither of them are. Documentation is documentation. Comments are documntation. Design docs and specs are documentation.
Tests, and especially the way most practices propose tests should be written, could not be farther from documentation.
> The invented practices you have presented throughout the discussion no doubt lead to writing useless tests.
Indeed they do.
> It is, however, not clear why you hang on this invention of yours – outright ignoring what you are being given.
So you have fabricated this idea that I am ignoring something and is now attempting to make me defend this fabrication of yours.
Quite likely given the exact example we speak of. Not likely for all cases.
> You will likely not propagate those to the end user, but log and return a single error for many of those cases
Agreed. But your code still has to get there and, unless you've given up on testing, test that each of those potentially hundreds of error states leads to the single error response with the appropriate log that you expect.
If you don't put any thought into testing upfront, this is where you can quickly end up with a mess that does really take too long to add testing to. And let's face it, those without much testing experience don't know much about what could be done to not create such a testing nightmare. I see it time and time again.
No need for religion. Do whatever you want and if you understand the tradeoffs are no doubt you are better off for it. But a lot of developers without much experience don't understand the tradeoffs.
> You write the tests to make sure your app conforms to documented behaviour.
Yes, exactly. And the document that documents said behaviour is.... Your tests. Not a bad practice to have additional documentation on top, but the tests will ultimately be your source of truth. They serve as the documentation that the code is tested against.
> Tests, and especially the way most practices propose tests should be written, could not be farther from documentation.
Go on. Are you creating your own unusual definition up on the spot here for the word documentation or is there something more profound in here?
> So you have fabricated this idea that I am ignoring something and is now attempting to make me defend this fabrication of yours.
I have observed this idea that you are ignoring what I've written. It's right there. I write something, you immediately reject it without any curiosity and then go off on some unrelated tangent that has nothing to do with what was said to justify your rejection. It is quite curious.
It could be that you simply don't understand, but normally when people don't understand they want to learn. Education is usually considered a desirable quality. Which left me wondering if this behaviour is some kind of defence mechanism to see that you don't gain any insights into other ways of working to protect what you feel is best?
Most likely hundreds. Each individual external service will easily have tens of conditions (a multitude of invalid input states, a multitude of malformed response payload states, a multitude of expected upstream error conditions, network interruption, port exhaustion, expired/invalid certificates, failed authentication/authorization, timeouts, etc., etc.) and when multiplied across them it won't be long before you have hundreds.
> Tests are not written to document behaviour, but to validate that your program does what it's supposed to do
A common misconception, but no. Tests would serve no purpose if you had no reason to document expected behaviour. Correct that tests also allow the machine to validate that what the documentation says is true, solving for the problems of the past where documentation and implementation would regularly fall out of sync. That is, indeed, the value proposition over writing the same information in Word instead.
Your documentation doesn't end there, of course, just as the documentation provided by a static type system is not the be all and end all of your documentation. But documentation it most certainly is.
> Existing testing practices all but enforce writing useless tests
The invented practices you have presented throughout the discussion no doubt lead to writing useless tests. It is, however, not clear why you hang on this invention of yours – outright ignoring what you are being given. Is it some kind of defence mechanism to protect the methods you have developed for yourself?