Hi, If you make the lifelong habit to write all of your code in a certain way. Then it will not be ambiguous and hard to understand. Then looking at it you can see what it is supposed to do. There are other things you can do to avoid testing too.
When testing is really needed is for certain kinds of projects. Military Spec. Aircraft, compliance and other kinds of embedded and safety critical systems. In those fields, the software code itself should be written (at significantly higher cost) to be 100% verifiable. So then it is treated somewhat like a state machine / turing machine. Same for VHBL and FPGA / other hardware designs. In those cases too, at least the integration testing must always be done separately. Not by the same software team, or with the same software tools. So yes - you can write unit tests. But it is largely a duplication of your own code and isn't guaranteed to prove anything except in the situation where your APIs are stable. I.e. for large quantities of what is basically only ever going to be regression testing. (previously implemented features). That is more needed in large-codebase and multi-developer (or multi-team) environments. Where one hand may not know it is covering / breaking the other. The take away point of all that ^^. Is that such testing typically cannot help you catch bugs in new features. So it's value is actually somewhat eroded / less costs are saved vs time spend coding the unit tests. In other words - you get more bang-for-buck directly fixing bugs in the existing code that's there or writing entirely new code / new features. And in software developer time is high cost… so nothing surprising really. On Sun, Mar 29, 2015 at 10:23 PM, Laurent Bercot <ska-skaw...@skarnet.org> wrote: > On 2015-03-28 15:36, Lorenzo wrote: > >> It's been a month, and no replies... but hey, "please contact me", >> does it mean there's been some progress in private discussions? >> > > I wish. But unfortunately, it looks like testing is as unappealing > to other people as it is to me. :) > (Not that I blame anyone. I can't be bothered to write tests for > my own freakin' projects, so why would it be surprising that nobody > wants to write tests for a project they don't even own ? It's really > a case of "there are all kind of fetishes in the world and I'm hoping > to find somebody with a compatible one". Which is a numbers game, > and we don't have the numbers yet.) > > > If not, I've spent a few hours looking at possible candidates that >> match your criteria(*), and some candidates actually survived. >> > > Awesome! I'm all ears. > > > Please tell me that someone mailed you in private anyway :) >> > > The silence in my mailbox was deafening. The community is still too > small so the odds are against me. :) > I hope to make the community larger with the projects I'm currently > working on; I can still keep things under control until then at least. > > -- > Laurent >