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