On Thu, Oct 22, 2020 at 8:06 AM Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > > On Wed, Oct 21, 2020 at 10:47:50AM -0700, Daniel Latypov wrote: > > On Tue, Oct 20, 2020 at 8:40 PM David Gow <david...@google.com> wrote: > > > On Tue, Oct 20, 2020 at 6:46 AM Daniel Latypov <dlaty...@google.com> > > > wrote: > > > > > > > > Add basic test coverage for files that don't require any config options: > > > > * gcd.c > > > > * lcm.c > > > > * int_sqrt.c > > > > * reciprocal_div.c > > > > (Ignored int_pow.c since it's a simple textbook algorithm.) > > > > > > > I don't see a particular reason why int_pow.c being a simple algorithm > > > means it shouldn't be tested. I'm not saying it has to be tested by > > > this particular change -- and I doubt the test would be > > > earth-shatteringly interesting -- but there's no real reason against > > > testing it. > > > > Agreed on principle, but int_pow() feels like a special case. > > I've written it the exact same way (modulo variable names+types) > > several times in personal projects. > > Even the spacing matched exactly in a few of those... > > But if you would like to *teach* somebody by this exemplary piece of code, you > better do it close to ideal. > > > > > These tests aren't particularly interesting, but > > > > * they're chosen as easy to understand examples of how to write tests > > > > * provides a place to add tests for any new files in this dir > > > > * written so adding new test cases to cover edge cases should be easy > > > > > > I think these tests can stand on their own merits, rather than just as > > > examples (though I do think they do make good additional examples for > > > how to test these sorts of functions). > > > So, I'd treat this as an actual test of the maths functions (and > > > you've got what seems to me a decent set of test cases for that, > > > though there are a couple of comments below) first, and any use it > > > gains as an example is sort-of secondary to that (anything that makes > > > it a better example is likely to make it a better test anyway). > > > > > > In any case, modulo the comments below, this seems good to me. > > > > Ack. > > I'll wait on Andy's input before deciding whether or not to push out a > > v2 with the changes. > > You need to put detailed comments in the code to have it as real example how > to > create the KUnit test. But hey, it will mean that documentation sucks. So, > please update documentation to cover issues that you found and which motivated > you to create these test cases.
I don't entirely disagree; leaning too heavily on code examples can be detrimental to docs. That being said, when I use other people's code, I often don't even look at the docs. So, I think the ideal is to have both. > Summarize this, please create usable documentation first.
