On Wed, Dec 08, 2021 at 11:26:59PM +0900, Takashi Sakamoto wrote: > On Tue, Dec 7, 2021, at 23:25, Mark Brown wrote: > > I do think there's an advantage for test comprehensibility in having the > > test written in terms of similar APIs to a normal userspace application > > - it makes it easier to relate what the test is doing to normal usage > > which is helpful when trying to understand what the test is trying to > > tell you. > In my opinion, test is merely test. It's not a sample program. > What important is what is tested. and how to assist developers if failed. > If more suitable for the direction, we should do it, even if using raw ioctl > in the case. Sure, but it's also important that if someone sees a test failure they can figure out what was being tested and if the test makes sense - there are plenty of testsuites out there with tests where what the problems are in the test, or it's hard to tell what the test is even supposed to be verifying. Putting barriers in the way of understanding the test means it's that bit harder to get people to put in the work required to figure out what the test is trying to tell them and pay attention to it. > For your information, `check_event()` in `test/user-ctl-element-set.c`, my > rough implementation of test for event triggered by tlv operation, might > be helpful to you or start point t to discuss about event check. Thanks. The main issue here is finding time to look at stuff rather than figuring out the APIs, they're reasonably easy to work with fortunately.
Attachment:
signature.asc
Description: PGP signature
