You're focusing too much on processes and methods. "What" should be your focus, not "how". For example it's paramount to test your software, but whether this is TDD or not is secondary.

As for reinventing the wheel, which library are you missing? I'm skeptical you cannot find a good library for your need.

You might not have the "automated tests" you are looking for, but maybe the library has been field tests for ten years which beats any automated test.

The real downside is that you cannot install libraries has easily as in "gem install library".

> For example it's paramount to test your software, but whether this is TDD or not is secondary.

If you don't examine your motivations for writing tests, and evaluate whether they're being fulfilled, how do you know their necessity is paramount?

It's difficult to know if your software works if you don't test it.

Right. But that's not the only reason to write tests, and presumably if your tests were giving you false positives, you'd want to note and address that. If "are my tests telling me when my software fails?" is a valid question to ask oneself, surely so is "are my tests telling me when my design is flawed?"

Of course, you might not believe that design feedback is an important motivation for writing tests, which is absolutely fine, but then the issue isn't that the OP is "focusing too much on process and methods" - he simply has different processes and methods to you.

Unless you're Knuth. But I'm not, so I test.

It's really interesting what you say about automated tests. I completely agree that tests are generally non-existent in libraries, which is a shame as they often document how a library is supposed to be used when they do exist, as well as preventing bugs.

> ... document how a library is supposed to be used when they do exist ...

That will also depend on the library. In my library projects there is no way you'd figure out good/normal library usage because the vast majority of the test code is exploring edge cases and things that go wrong. I have 96-99% coverage which means there is a lot of non-normal usage tested. For example consider getting the length of something. Normal usage would just ask for it. Test code has to check different types, null pointers (if applicable), broken iterators, running out of memory and various other issues.

I do however have very comprehensive documentation including lots of example code. That of course is what the projects should provide rather than expecting reverse engineering of the test suite.

The Ruby community is exemplary in this regard, something I totally took for granted.

The reason for the exemplary unit testing in Ruby (it's not just Ruby... Python and other dynamic languages too) is that these languages do not have a compiler.

They have to unit test everything in order to catch bugs and not all bugs are caught by unit testing hence programs such as pylint try to do things that C++ compilers do every time the code is compiled. You can and should still unit test C++ code to make sure that data are as you expect, etc. A good compiler with all warnings turned on is very helpful.

Too soon & too small a project to report progress. The conclussions are not new.

For all intents and purposes an insignificant piece of information. Flagged.

--

Edit: the touchy-feely crowd downvoted me to -4 for telling what is essentially the truth but without much finesse. Ok. Let me put it this way: 7-days and one user is NOTHING in software engineering. What exactly are reporting here?

HN guidelines:

"Please don't submit comments complaining that a submission is inappropriate for the site. If you think something is spam or offtopic, flag it by going to its page and clicking on the "flag" link. (Not all users will see this; there is a karma threshold.) If you flag something, please don't also comment that you did."

I down-voted you for flagrantly abusing the flagging mechanism