[GitHub] [incubator-nuttx-apps] xiaoxiang781216 edited a comment on pull request #538: system: nxlooper: add nxlooper for loopback test

[GitBox <gi...@apache.org>]

xiaoxiang781216 edited a comment on pull request #538:
URL: https://github.com/apache/incubator-nuttx-apps/pull/538#issuecomment-749613212


   > > > Should this go under apps/testing instead of apps/system?
   > > 
   > > 
   > > Other two audio tools put to apps/system:
   > > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxplayer
   > > https://github.com/apache/incubator-nuttx-apps/tree/master/system/nxrecorder
   > > The new place make nxlooper hard to find by people who is already familiar with nxplayer/nxrecorder.
   > > @patacongo do you think so?
   > 
   > I don't have any strong opinion. nxplayer and nxrecorder are not tests, they are applications. nxlooper is a test so it is functionally misplaced. It is a test that is place in the same directory as its related applications. I understand the logic for either location.
   > 
   
   The design of nxlooper is very closed to nxplayer, e.g. there is a simple interpreter to accept user command after launching nxlooper. And nxlooper more like a debugging tool to diagnose the audio driver functionality and then require the developer verify the result by ear manually.
    
   > How would you want this to work in the the future? Should tests be scattered all over in different directories are consolidated under testing?
   > 
   
   Yes, it's better to move the application which design for testing(which mean run and report automatically) to apps/testing.
   
   > There is a similar kind of issue with examples/ and testing/. A test often makes a good example and most examples were developed as superficial tests. But the idea is that an example is a HowTo for use of a feature that probably does not have a lot of depth. A test should have better coverage and may not necessarily be a good HowTo application.
   > 
   > Ideally, it should be possible to automate tests and they should conform to some pass/fail reporting rules. Examples, just report results in user friendly text. But none of that has been thought through much less implemented.
   
   Yes, this is what I am thinking: let's program under apps/testing report pass/fail with zero/nozero exit code, then we can develop a test driver nsh script to manage all tests automatically. Actually, @ttnie is working on this.
   
   From this perspective, apps/system is more suitable place for nxlooper, because:
   
   1. It's hard to very the result of nxlooper
   2. nxlooper is more useful for driver bringup
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org