<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 26, 2021 at 2:34 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/24/21 6:27 PM, enh wrote:<br>
> yeah, i think he (and i, when i have my bionic hat on) have an easier problem<br>
> than you ... this kind of thing isn't too hard in the c library because it's<br>
> generally considered okay to just shrug and return -1 with errno == ENOSYS or<br>
> whatever.<br>
> <br>
> whereas as an "app", your users expect you to do the thing. (which at best tends<br>
> to mean you have an untested/barely tested "success" case. no-one worries that<br>
> their return -1 has bitrotted, but the non-inotify path or the non-O_TMPFILE or<br>
> whatever ... that's a lot more likely!)<br>
<br>
I keep telling people I could spend a focused year on JUST the test suite and<br>
they don't believe me. When people talk about function testing vs regression<br>
testing vs coverage testing I get confused because it's all the same thing? </blockquote><div><br></div><div>i'll include the main failure modes of each, to preempt any "yes, but"s by admitting that _of course_ you can write fortran in any language, but the idea is something like:<br><br>integration testing - answers "does my product work for real use cases?". you definitely want this, for obvious reasons, and since your existing testing is integration tests, i'll say no more. other than that the failure mode here is relying only on integration tests and spending a lot more time/effort debugging failures than you would if you could have caught the same issue with a unit test.<br><br>unit testing - reduces the amount of digging you have to do _when_ your integration tests fail. (also makes it easier to asan/tsan or whatever, though this is much more of a problem on large systems than it is for something like toybox, where everything's small and fast anyway, versus "30mins in to transcoding this video, we crash" kinds of problem.) for something like toybox you'd probably be more interested in the ability to mock stuff out --- your "one day i'll have qemu with a known set of processes" idea, but done by swapping function pointers. one nice thing about unit tests is that they're very easily parallelized. on a Xeon desktop i can run all several thousand bionic unit tests in less than 2s... whereas obviously "boot a device" (more on the integration test side) takes a lot longer. the main failure mode here (after "writing good tests is at least as hard as writing good code", which i'm pretty sure you already agree with, and might even be one of your _objections_ to unit tests), is writing over-specific unit tests. rather than writing tests to cover "what _must_ this do to be correct?" people cover "what does this specific implementation happen to do right now, including accidental implementation details?". (i've personally removed thousands of lines of misguided tests that checked things like "if i pass _two_ invalid parameters to this function, which one does it report the error about?", where the correct answer is either "both" or "who cares?", but never "one specific one".)<br><br>coverage - tells you where your arse is hanging out the window _before_ your users notice. (i've had personal experiences of tests i've written and that two other googlers have code reviewed that -- when i finally got the coverage data -- turned out to be missing important stuff that [i thought] i'd explicitly written tests for. Android's still working on "real time" coverage data showing up in code reviews, but "real Google" has been there for years, and you'd be surprised how many times your tests don't test what you thought they did.) the main failure mode i've seen here is that you have to coach people that "90% is great", and that very often chasing the last few percent is not a good use of time, and in the extreme can make code worse. ("design for testability" is good, but -- like all things -- you can take it too far.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You<br>
have to test every decision point (including the error paths), you have to<br>
exercise every codepath (or why have that codepath?) and you have to KEEP doing<br>
it because every distro upgrade is going to break something.<br></blockquote><div><br></div><div>yeah, which is why you want all this stuff running in CI, on all the platforms you care about.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my private emails somebody is trying to make the last aboriginal linux<br>
release work and the old busybox isn't building anymore because makedev() used<br>
to be in #include <sys/types.h> and now it's moved to <sys/sysmacros.h>. (Why? I<br>
dunno. Third base.) </blockquote><div><br></div><div>the pain of dealing with that pointless deckchair crap with every glibc update is one reason why (a) i've vowed never to do that kind of thing again in bionic [we were guilty of the same crime in the past, even me personally; the most common example being transitive includes] and (b) i'm hoping musl will care a bit more about not breaking source compatibility ... but realize he's a bit screwed because code expecting glibc might come to rely on the assumption that <sys/types.h> *doesn't* contain makedev(), say --- i've had to deal with that kind of mess myself too. sometimes you can't win.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And yes I confirmed that version skew using the Centos<br>
release that other guy poked me about last week. It has the old one, my laptop<br>
(and <a href="http://man7.org" rel="noreferrer" target="_blank">man7.org</a>) has the new one, it changed somewhere in between, no idea why.<br>
<br>
Linus is much better about avoiding this in the kernel, but you still get it<br>
with the /sys directory because Greg KH is SUCH an asshole. And Peter Anvin is<br>
on a mission to add gratuitous build dependencies to every project he touches<br>
for reasons I've never understood despite repeatedly asking him to explain...<br>
<br>
Rob<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>