Comment by randomdata | Hacker News Reader

Comment by randomdata | Hacker News Reader

Parent Full thread

> Because what would be that "first one test"?

Whatever you want. Just pick some small attribute that you expect to observe.

I'd personally start with failure modes as they are the most important and interesting code you will write. Hell, you can likely not even bother testing the so-called "happy path" because, really, who cares what happens during success? Failure is where you want users and future readers to have the most documentation to ensure that when things go wrong the metaphorical bridge doesn't come crashing down into the river but rather remains in a repairable state.

If it's a REST endpoint that aggregates data from multiple external services, you probably want to see a "retry after" response sent to the client if any of those external services are temporarily unavailable. So write a test that asserts that, then write code that does it. This is also a nice first case as you can detect an unavailable external service quite early in your pipeline, requiring very little of the implementation to see the test pass.

No need for religion. If documenting your code later works for you, go for it. Nobody cares. Tests won't be driving your development, so it won't be TDD, but it'll be something and that may be enough. However, in reality most people simply don't have the wherewithal to plan for things like being able to test unavailable remote services if they don't have a test case in front of them forcing them to and won't bother when it is too hard to add later, so there is something to be said about the TDD approach as a general rule, deviating only after you fully understand the tradeoffs.

> Just pick some small attribute that you expect to observe.

The expected "attribute" is correct data being returned.

> Hell, you can likely not even bother testing the so-called "happy path" because, really, who cares what happens during success?

wat?

> If it's a REST endpoint that aggregates data from multiple external services, you probably want to see a "retry after" response sent to the client if any of those external services are temporarily unavailable. So write a test that asserts that, then write code that does it.

So again you want me to write a meaningless test that will be duplicated anyway during the actual proper test. See https://news.ycombinator.com/item?id=34765360

> However, in reality most people simply don't have the wherewithal to plan for things like being able to test unavailable remote services if they don't have a test case in front of them forcing them

This is a weird statement that is definitely not backed up by reality.

> there is something to be said about the TDD approach as a general rule, deviating only after you fully understand the tradeoffs.

The problem is, everyone advocates writing multiple useless tests, including TDD proponents. You can't learn "tradeoffs" until you look past the dogma. Once you've looked past the dogma these "tradeoffs" most of them are not tradeoffs, but trivial things that you would do anyway.

> The expected "attribute" is correct data being returned.

Even in the simple example given, there are probably hundreds of different failure cases to account for. The "correct data being returned" will never be a single attribute unless your application does effectively nothing.

> wat?

The successful case is usually the most understood behaviour, most visible, and easiest to recreate. If you are going to skimp out on documenting some aspects of your code because you hate future developers, the most understood aspect is where you are best to skimp.

> So again you want me to write a meaningless test that will be duplicated anyway during the actual proper test.

No. Why would you write the same documentation over and over again? This makes no sense.

> This is a weird statement that is definitely not backed up by reality.

It is certainly backed up every time I have worked with developers who put no effort into making their code testable, making it way harder than it should be to test certain cases afterwards. And in my experience they usually just throw their hands up in the air and say "testing takes too long" after they've made it unnecessarily hard to test.

Is it that you always work alone? If so, I can see why you think documentation isn't that useful. If you have a decent memory, it probably isn't. But most people have to work in teams or are in positions where they will one day be replaced and aren't writing documentation for just for themselves.

After all, that's what TDD – and, really, testing in general – is all about: Documentation.

> The problem is, everyone advocates writing multiple useless tests

Nobody advocates writing useless tests. Future readers should be able to learn something useful from every documentation item you write. That your function will return "retry after" when an upstream service is temporarily unavailable is very useful information for users and future developers to know. This is worth documenting.

You will undoubtedly need to write multiple tests. Nobody wants to read documentation that is one big ball of mud. A sane developer will break different cases into different tests to help future readers clearly understand that there are different environmental cases, like the range of failure states, to consider.

> Even in the simple example given, there are probably hundreds of different failure cases to account for.

Definitely not hundreds. But yes, they need to be tested

> The successful case is usually the most understood behaviour, most visible, and easiest to recreate.

Tests are not written to document behaviour, but to validate that your program does what it's supposed to do. If you don't test successful cases, you don't even know if it runs correctly.

> If you are going to skimp out on documenting some aspects of your code because you hate future developers, the most understood aspect is where you are best to skimp.

I see you have the erroneous assumption that tests are documentation.

> It is certainly backed up every time I have worked with developers who put no effort into making their code testable, making it way harder than it should be to test certain cases afterwards.

This is slightly orthogonal to being able to write testable code etc. Most tests are trash to begin with, and most testing frameworks give next to zero help in designing and running actual tests you would really want.

I couldn't care less if a team mate wrote "untestable code" in some modules. In 99% of the time that code is some repetitive boilerplate anyway. Ironically, this is the code that everyone prioritises to make testable.

And then you want to test all that in concert... Ahahaha good luck. Even starting up a local rest service with mocked dependencies to test is a royal pain in the butt in most cases, and has nothing to do with testability of some small pieces of code.

> that's what TDD – and, really, testing in general – is all about: Documentation.

Tests are not documentation, have never been, and can never be viewed as such.

Testing is literally about testing: to test that your program behaves correctly given some requirements. It literally is in the name. You write tests not to educate your co-workers, but to make sure your program doesn't crash and burn the moment you push it to prod.

> Nobody advocates writing useless tests. Future readers should be able to learn something useful from every documentation item you write.

Again:

1. Tests are not documentation. Have never been, will never be.

2. Existing testing practices all but enforce writing useless tests, prioritising duplication, hundreds of unit tests etc. over what' actually needed.

> Nobody wants to read documentation that is one big ball of mud.

All tests are inevitably a ball of mud because they lack context, and they are not documentation.

> 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?

> Most likely hundreds.

Not likely

> 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.

> Not likely

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?

Reply on news.ycombinator.com