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 <dev_AT_frign.de> wrote:
> On Tue, 24 Feb 2015 13:58:16 -0800
> Louis Santillan <lpsantil_AT_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 <dev_AT_frign.de>
>
Received on Wed Feb 25 2015 - 01:53:06 CET