[PATCH v2] kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest

Mark Brown broonie at kernel.org
Wed Dec 8 17:07:15 CET 2021


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20211208/4233b837/attachment.sig>


More information about the Alsa-devel mailing list