Of course I understand there's some C++ stuff in there. Throw it out. Not necessary. Two methods is all you need, his plan() & ok(). Testing, IMO, is always good. You speak about well-designed interfaces. How do you know if some implementation detail change breaks your usage? And lets say this implementation is still compliant to the interface. A test could help you with that. A well-designed interface is still not a perfect interface, nor is it the same thing as perfect/correct usage of such an interface. However, those things are easy to test. As for test coverage, a well-designed interface deserves a well-designed test case.
On Tue, Feb 24, 2015 at 2:21 PM, FRIGN <d...@frign.de> wrote: > On Tue, 24 Feb 2015 13:58:16 -0800 > Louis Santillan <lpsan...@gmail.com> wrote: > > Hey Louis, > >> I'm a fan of TAP frameworks [0]. Very minimal, easy to roll you own, >> consumable by many Unix tools, human & machine readable. clibs links >> to a bunch of pre-written libs as well [1]. kazuho had written this >> 35 line example of a lib [2] that exports all you need to basic TAP, >> which is like 75% of all TAP. See an example usage here [3]. > > you do realize this is written in C++? Come to think of it, what's the > purpose of that? You could use asserts then anyway. And asserts are bad, > same applies to any unit testing in smaller projects. > > If you projects grow too large, there might be some reason to have tests, > but as already discussed earlier, if you are careful, things won't out- > grow on a well-designed interface and if you set up tests, they often > end up covering one are but not the other. > > Cheers > > FRIGN > >> [0] http://en.wikipedia.org/wiki/Test_Anything_Protocol >> [1] https://github.com/clibs/clib/wiki/Packages#testingquality-assurance >> [2] https://github.com/kazuho/picogc/blob/master/t/test.h >> [3] https://github.com/lpsantil/picotap/blob/master/t/test.c > > -- > FRIGN <d...@frign.de> >
