[bobwaycott]

Is it just the presence of "tests" that are going to provide this ease of mind for these hypothetical future users? And exactly how would these desired tests provide demonstrable help for maintainability. It's a small project. The creator knows what it does. If s/he adds more features, I'd be willing to bet s/he will know if s/he breaks something.

Moreover, who is to say these desired tests actually test anything meaningful. If there was a set of tests, would you actually read through the tests to determine they did something substantial and meaningful for the project, and weren't just terrible nonsense added in that don't actually test anything at all that matters? Or would you simply see there were tests and feel this peace of mind and think to yourself they will help for maintainability (maintenance you probably aren't doing yourself).

In short, is it tests you want, or simply peace of mind?

[kevindeasis]

testing is used to be more productive in the long run. [1]

I feel like there are numerous amount of developers who write code, and in the future would forget if they have created bugs or would not remember exactly everything that their code does.

http://nparc.cisti-icist.nrc-cnrc.gc.ca/npsi/ctrl?action=shw...

Would it not be smart to write test code that actually test anything meaningful, because who would want to write testing that is not meaningful?

So would ease of mind not come from proper testing?

[bobwaycott]

What I was getting at is that the original comment under which we are discussing was suggesting that "having tests" was a reason to not use the project ... and that's poor reasoning. To your points specifically, I'm saying the existence of tests does nothing to provide any meaningful, dependable, worthwhile benefits.

Regarding a couple of your points ...

- How can tests at all help a developer remember anything about their code in the future? That's what documentation is for.

- Sure, tests can help quickly identify bugs. Tests are supposed to identify when a problem has been introduced, or verify that code meets expectations. But that itself depends on the tests being correct.

- To depend on tests, you need meaningful, accurate tests that were properly thought out and implemented. If a project has tests, but those tests were poorly thought out, don't adequately cover complicated, critical parts of code, what good are they?

- Sure, peace of mind can come from proper testing. However, that requires the tests to actually be proper. What does that mean? How does that get defined and implemented? Designing and implementing tests is, in my opinion, quite different from writing some code that does a thing--especially as the complexity of the code increases.

- That tests exist for a project, or that tests are absent from a project, is to me a poor reasoning for using or not using a given project. This was the original commenter's point--that the project would not be used because it did not have tests. That tells absolutely zilch about the quality and dependability of the project. Moreover, if tests did exist, and one wanted to judge whether or not to use a project, one would need to actually read the tests, and the code they test, and then determine if the tests properly cover what matters. At least then, the original commenter may have been adding something helpful to the discussion. Identifying that a project's tests do not actually provide any meaningful proofs is an important thing to do. I don't think too many people actually do that when they judge a project on the existence of tests.

Full disclosure of my own related weakness:

For me, the existence of documentation is a much more important metric for decisions on whether to use a project or not. But if I were to say, "Doesn't have (or does have) docs; will therefore use/not use", I'm not really making much of a quality decision here. That's why I actually check out the docs. I read them and see whether they actually cover enough material to use a project, or if they are hastily written and not a reliable help. However, sometimes there aren't formal docs at all. So, I might take a look at the code, and find incredibly well-documented code in comments throughout the project. If I just make a decision to reject a project based on the maxim "doesn't have docs", I wind up missing that there actually is extensive documentation ... just not where I may have been looking.

The same should be done for tests, I think.