On Wed, Mar 09, 2016 at 01:25:22PM +0100, Peter Steinbach wrote: > On 03/09/2016 01:15 PM, Ashwin Trikuta Srinath wrote: > > I'm in favour of teaching testing - even if it is in the style of > > the regression tests you mentioned. But I'm not so sure about unit > > tests, or even if application code built on libraries can/should > > be "unit" tested. > > Well, I would very emotionally start arguing against this. As unit > tests are my day-to-day tool that I use for application and for > library code and they have rescued my !*&^% multiple times. As most > of my tasks involve accelerating applications, I always say no > speed-up is of use if the results are wrong. > > But maybe I don't see your point, can you please elaborate!
I'd guess the issue is “if the application unit test fails, was the application code wrong or was the library code wrong?”. But that's not specific to the application ↔ library interface. If your machine code unit test fails, is it a bug in your machine code or in your processor? If your C library unit test fails, is it a bug in your library code or in your C compiler? Trying to draw a hard line between “unit testing” and “integration testing” doesn't seem particularly useful. I think the solution is to prefer lower layers that have good test coverage and/or wide deployment. And if they're open source, you can usually contribute patches to improve poor testing (although this takes time; see [1]). Cheers, Trevor [1]: http://ivory.idyll.org/blog/2016-containerization-disaster.html -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
