apps/testing:move {drivertest fftest irtest monkey nand_sim pcitest sd_bench sd_stress sensortest} folders to the new driver folder

[txy-21]

Summary

This is one step that merge test case as discussed in #2931.
Create driver folder and move {drivertest fftest irtest monkey nand_sim pcitest sd_bench sd_stress sensortest} folders to the new driver folder.

Impact

This PR only affects the apps/testing folder, changing the location of some subfolders under this folder.
new folder : driver
move : drivertest fftest irtest monkey nand_sim pcitest sd_bench sd_stress sensortest

Testing

CI test.

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary and describes the impact, it lacks crucial information.

Here's what's missing:

• Summary: While the summary explains what is being done, it lacks the why. What problem does moving these test folders solve? How does this relate to the linked PR? Is this a cleanup effort? Is it preparing for future work? The summary needs to justify the change. It also needs the corresponding NuttX issue reference if one exists.
• Impact: While the PR mentions affected files, it doesn't explicitly answer all the required impact questions with YES/NO followed by details if applicable. Even if the answer is NO, stating it explicitly ensures reviewers don't have to guess. For example:
  • Impact on user: NO
  • Impact on build: Potentially YES (if any build scripts relied on the old paths. Even if unlikely, this needs to be considered).
  • Impact on hardware: NO
  • Impact on documentation: YES (Any documentation referencing these test applications will need updating).
  • Impact on security: NO
  • Impact on compatibility: Potentially YES (if external scripts or tools rely on the old paths).
• Testing: "CI test" is insufficient. The requirements explicitly request testing logs before and after the change. Even if the CI passes, providing snippets of relevant output demonstrating the tests still function as expected would greatly improve the PR. Also, details of the build host and target are missing.

In short, the PR needs more detail and explicit answers to the checklist items to be considered complete. While the changes themselves might be simple, demonstrating due diligence in the PR description is essential for proper review and acceptance.

[cederom]

Thank you @txy-21 :-)

[cederom]

Didn't we want drivers/? :-P

[txy-21]

@cederom ok, change driver to dirvers

[txy-21]

@cederom Thanks for your suggestion.About irtest,sd_bench,monkey and sensortest folders, @xiaoxiang781216 has a different suggestion. His opinion is somewhat different from what we discussed in #2931. What do you think of his suggestion?

[cederom]

@txy-21: @cederom Thanks for your suggestion.About irtest,sd_bench,monkey and sensortest folders, @xiaoxiang781216 has a different suggestion. His opinion is somewhat different from what we discussed in #2931. What do you think of his suggestion?

Always good to discuss :-) Maybe better solution can be found that way :-)

[cederom]

Okay it seems @raiden00pl remarks on separating apps/testing into testing utilities (something to perform the tests) and apps/tests test scenarios (list of specific tests that returns PASS/FAIL) makes more sense now. This is also what @xiaoxiang781216 suggests right now :-)

What would be better / possible approach for now @txy-21 @xiaoxiang781216 ?

1. apps/testing cleanup by organizing existing stuff by function first then identify test cases and move them next to apps/tests based on categories created in apps/testing?
2. Use current time/work and split apps/testing/function and apps/tests/function right away?

Update: From the specific comments above it seems also some utilities in the apps/testing can be moved out into function specific location as these are more generic utilities / applications not really testing dedicated stuff?

[xiaoxiang781216]

@GUIDINGLI suggest we move the tools/utils to apps/system and benchmark to apps/benchmark.

[raiden00pl]

@xiaoxiang781216 I thought the same - we can move some tools back to apps/system and some to apps/benchmark. But what about cmoka , unity and fff? These fits quite well in apps/testing. Maybe something like this:

• programs that return pass/fail output - apps/tests
• testing frameworks to be used by user- apps/testing
• performance tests - apps/benchmark
• small testing apps that doesn't fit above - apps/system

[cederom]

I liked the @txy-21 idea that some testing utils for instance targeted for drivers tests could be placed in the apps/testing/drivers (or similar).. but looking at apps/system most programs there are testing utilities already.. the same with benchmarks :-) So apps/testing should be reserved for testing frameworks only according to original concept?

For sure @xiaoxiang781216 initial remarks here on what are "tests" in terms to return PASS/FAIL are in align with previous discussion @raiden00pl suggestions and I fully agree these should be separated and apps/tests seems best / standard / acclaimed location :-)

[xiaoxiang781216]

@xiaoxiang781216 I thought the same - we can move some tools back to apps/system and some to apps/benchmark. But what about cmoka , unity and fff? These fits quite well in apps/testing. Maybe something like this:

• programs that return pass/fail output - apps/tests
• testing frameworks to be used by user- apps/testing

I prefer that testing frameworks and test case under one top level folder(either tests or testing is fine to me), we can move the testing testing/framework to testing/utils or frameworks etc.

• performance tests - apps/benchmark
• small testing apps that doesn't fit above - apps/system

LGTM.