findutils icon indicating copy to clipboard operation
findutils copied to clipboard

Port findutils to use uutests

Open sylvestre opened this issue 8 months ago • 4 comments

Currently, the tests are custom. we should move to our framework for consistency.

The doc is here: https://docs.rs/uutests/0.0.30/uutests/

Some examples of usage: https://github.com/uutils/coreutils/blob/main/tests/by-util/test_ls.rs https://github.com/uutils/coreutils/blob/main/tests/by-util/test_cp.rs

To do it: tests/common/mod.rs

diff --git a/tests/common/mod.rs b/tests/common/mod.rs
index aa8de37..d69371b 100644
--- a/tests/common/mod.rs
+++ b/tests/common/mod.rs
@@ -8,3 +8,13 @@
 // in one test but not another can cause a dead code warning.
 #[allow(dead_code)]
 pub mod test_helpers;
+pub const TESTS_BINARY: &str = env!("CARGO_BIN_EXE_find");
+
+// Use the ctor attribute to run this function before any tests
+#[ctor::ctor]
+fn init() {
+    unsafe {
+        // Necessary for uutests to be able to find the binary
+        std::env::set_var("UUTESTS_BINARY_PATH", TESTS_BINARY);
+    }
+}

Cargo.toml:

diff --git a/Cargo.toml b/Cargo.toml
index 6ed7124..43b09d0 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -19,6 +19,9 @@ onig = { version = "6.4", default-features = false }
 uucore = { version = "0.0.30", features = ["entries", "fs", "fsext", "mode"] }
 nix = { version = "0.29", features = ["fs", "user"] }
 argmax = "0.3.1"
+uutests = { version = "0.0.30" }
+ctor = "0.4.1"
+
 
 [dev-dependencies]
 assert_cmd = "2"

And update:

  • tests/exec_unit_tests.rs
  • tests/find_cmd_tests.rs
  • tests/find_exec_tests.rs
  • tests/xargs_tests.rs

sylvestre avatar Apr 14 '25 20:04 sylvestre

I can try taking this!

Though I may be misunderstanding the updates to be made to exec_unit_tests.rs. From this comment that states:

/// ! This file contains what would be normally be unit tests for `find::matchers::exec`.
/// ! But as the tests require running an external executable, they need to be run
/// ! as integration tests so we can ensure that our testing-commandline binary
/// ! has been built.

My understanding is that these tests are not targeting the find CLI binary itself, but instead validate internal matcher logic (SingleExecMatcher, MultiExecMatcher) which invoke external executables as part of the test setup.

In that case, would converting exec_unit_tests.rs to uutests still be appropriate? Since uutests is geared toward CLI-level testing of the find binary?

This may be a misunderstanding on my part, feedback is much appreciated!

Cheers!

hz2 avatar Apr 15 '25 13:04 hz2

Silly question - can multiple people work on this? Or only one? I'm trying to break into open source and as someone who uses GNU findutils a lot, I'd like to be an additional pair of hands (but not immediately take ownership of getting it done).

sarnobat avatar Oct 07 '25 01:10 sarnobat

@sarnobat start from @hz2 work or restart from scratch

sylvestre avatar Oct 07 '25 05:10 sylvestre

Thank you. Note to self:

  • https://github.com/hz2/findutils
  • https://github.com/uutils/findutils/pull/541/files

To avoid middleman collaboration, I'm creating my own direct pull request and pulling @hz2 's changes: https://github.com/uutils/findutils/pull/578

sarnobat avatar Oct 08 '25 02:10 sarnobat