Add prefix to helper functions to prevent user code conflicts

CHANGELOG.md

@@ -5,6 +5,22 @@
 ### Changed
 - Build script now outputs to temp directory (`${TMPDIR}/bashunit/build`) by default instead of `bin/`
 - Add `--cleanup` flag to build script to remove build artifacts after completion
+- **BREAKING:** Namespace all helper functions to avoid conflicts with user code (fixes #538)
+    - `skip` → `bashunit::skip`
+    - `todo` → `bashunit::todo`
+    - `fail` → `bashunit::fail`
+    - `mock` → `bashunit::mock`
+    - `unmock` → `bashunit::unmock`
+    - `spy` → `bashunit::spy`
+    - `temp_file` → `bashunit::temp_file`
+    - `temp_dir` → `bashunit::temp_dir`
+    - `data_set` → `bashunit::data_set`
+    - `current_dir` → `bashunit::current_dir`
+    - `current_filename` → `bashunit::current_filename`
+    - `random_str` → `bashunit::random_str`
+    - `log` → `bashunit::log`
+    - `set_test_title` → `bashunit::set_test_title`
+    - All `assert_*` functions remain unchanged
 
 ### Fixed
 - Custom assertions now display the correct test function name in failure messages

docs/assertions.md

@@ -1140,8 +1140,8 @@ function test_failure() {
 ```
 :::
 
-## fail
-> `fail "failure message"`
+## bashunit::fail
+> `bashunit::fail "failure message"`
 
 Unambiguously reports an error message. Useful for reporting specific message
 when testing situations not covered by any `assert_*` functions.
@@ -1150,12 +1150,12 @@ when testing situations not covered by any `assert_*` functions.
 ```bash [Example]
 function test_success() {
   if [ "$(date +%-H)" -gt 25 ]; then
-    fail "Something is very wrong with your clock"
+    bashunit::fail "Something is very wrong with your clock"
   fi
 }
 function test_failure() {
   if [ "$(date +%-H)" -lt 25 ]; then
-    fail "This test will always fail"
+    bashunit::fail "This test will always fail"
   fi
 }
 ```

docs/common-patterns.md

@@ -414,7 +414,7 @@ function set_up() {
 }
 
 function test_get_current_branch() {
-  mock git echo "feature/new-feature"
+  bashunit::mock git echo "feature/new-feature"
 
   local branch
   branch=$(get_current_branch)
@@ -423,7 +423,7 @@ function test_get_current_branch() {
 }
 
 function test_check_for_changes() {
-  mock git <<EOF
+  bashunit::mock git <<EOF
 M  src/file1.sh
 A  src/file2.sh
 EOF
@@ -461,23 +461,23 @@ function set_up() {
 }
 
 function test_deployment_calls_docker_push() {
-  spy docker
+  bashunit::spy docker
 
   deploy_image "myapp:latest"
 
   assert_have_been_called docker
 }
 
 function test_docker_called_with_correct_arguments() {
-  spy docker
+  bashunit::spy docker
 
   deploy_image "myapp:v1.0.0"
 
   assert_have_been_called_with "push myapp:v1.0.0" docker
 }
 
 function test_deploy_calls_docker_twice() {
-  spy docker
+  bashunit::spy docker
 
   deploy_image "myapp:latest"
   deploy_image "myapp:v1.0.0"

docs/custom-asserts.md

@@ -59,14 +59,14 @@ function test_value_is_not_foo() {
 
 ### Using fail() for simple messages
 
-You can also use `fail` for custom assertions that just need a message:
+You can also use `bashunit::fail` for custom assertions that just need a message:
 
 ```bash
 function assert_valid_json() {
   local json="$1"
 
   if ! echo "$json" | jq . > /dev/null 2>&1; then
-    fail "Invalid JSON: $json"
+    bashunit::fail "Invalid JSON: $json"
     return
   fi
 
@@ -114,7 +114,7 @@ function assert_positive_number() {
 
 ## Best practices
 
-1. **Always return after failure**: Call `return` after `bashunit::assertion_failed` or `fail` to stop execution of your custom assertion.
+1. **Always return after failure**: Call `return` after `bashunit::assertion_failed` or `bashunit::fail` to stop execution of your custom assertion.
 
 2. **Always mark success**: Call `bashunit::assertion_passed` or `state::add_assertions_passed` when your assertion succeeds.
 

docs/data-providers.md

@@ -23,7 +23,7 @@ function test_my_test_case() {
 
 ## Implementing a data provider
 
-A data provider function contains one or more `data_set` lines. Each `data_set` results in a separate run of the test function with the individual `data_set` arguments being passed to it as positional arguments (`$1`, `$2`, ...).
+A data provider function contains one or more `bashunit::data_set` lines. Each `bashunit::data_set` results in a separate run of the test function with the individual `bashunit::data_set` arguments being passed to it as positional arguments (`$1`, `$2`, ...).
 
 Each run is treated as a separate test, so it can pass or fail independently. Plus, [set_up](/test-files#set-up-function) and [tear_down](/test-files#tear-down-function) are called before and after each run. This reduces code repetition and helps create related tests more efficiently.
 
@@ -32,18 +32,18 @@ A data provider function is implemented as follows:
 ::: code-group
 ```bash [Example]
 function provider_function() {
-  data_set "one"
-  data_set "two" "three"
-  data_set "value containing spaces"
-  data_set "" "first value is empty"
+  bashunit::data_set "one"
+  bashunit::data_set "two" "three"
+  bashunit::data_set "value containing spaces"
+  bashunit::data_set "" "first value is empty"
 }
 
 ```
 :::
 
 > **Note**: The previous variant of using `echo` to define data within a data provider
 > provider is still supported but deprecated, as it does not support empty values or
-> values containing spaces. Prefer using the `data_set` function going forward.
+> values containing spaces. Prefer using the `bashunit::data_set` function going forward.
 
 ## Interpolating arguments in test names
 
@@ -59,8 +59,8 @@ function test_returns_fizz_when_multiple_of_::1::_like_::2::_given() {
 }
 
 function fizz_numbers() {
-  data_set 3 4
-  data_set 3 6
+  bashunit::data_set 3 4
+  bashunit::data_set 3 6
 }
 ```
 ```[Output]
@@ -86,7 +86,7 @@ function test_directories_exists() {
 }
 
 function provider_directories() {
-  data_set "/usr" "/etc" "/var"
+  bashunit::data_set "/usr" "/etc" "/var"
 }
 ```
 ```[Output]
@@ -107,9 +107,9 @@ function test_directory_exists() {
 }
 
 function provider_directories() {
-  data_set "/usr"
-  data_set "/etc"
-  data_set "/var"
+  bashunit::data_set "/usr"
+  bashunit::data_set "/etc"
+  bashunit::data_set "/var"
 }
 ```
 ```[Output]
@@ -134,9 +134,9 @@ function test_directory_exists() {
 }
 
 function provider_directories() {
-  data_set "outro" "/usr"
-  data_set "outro" "/etc"
-  data_set "outro" "/var"
+  bashunit::data_set "outro" "/usr"
+  bashunit::data_set "outro" "/etc"
+  bashunit::data_set "outro" "/var"
 }
 ```
 ```[Output]

docs/globals.md

@@ -34,38 +34,38 @@ log "error" "hello" "world"
 ```
 Internal messages from bashunit include the `[INTERNAL]` prefix so you can easily spot them. You can enable them with `BASHUNIT_INTERNAL_LOG=true|false`.
 
-## current_dir
+## bashunit::current_dir
 
-> `current_dir`: Gets the current directory name.
+> `bashunit::current_dir`: Gets the current directory name.
 
-## current_filename
+## bashunit::current_filename
 
-> `current_filename`: Gets the current filename.
+> `bashunit::current_filename`: Gets the current filename.
 
-## caller_filename
+## bashunit::caller_filename
 
-> `caller_filename`: Gets the caller filename.
+> `bashunit::caller_filename`: Gets the caller filename.
 
 ## current_timestamp
 
 > `current_timestamp`: Gets the caller filename.
 
-## random_str
+## bashunit::random_str
 
-> `random_str <?length>`: generate a random string
+> `bashunit::random_str <?length>`: generate a random string
 
-## temp_file
+## bashunit::temp_file
 
-> `temp_file <?prefix>`: creates a temporal file
+> `bashunit::temp_file <?prefix>`: creates a temporal file
 
 The file is automatically deleted when bashunit completes.
 
-## temp_dir
+## bashunit::temp_dir
 
-> `temp_dir <?prefix>`: creates a temporal directory
+> `bashunit::temp_dir <?prefix>`: creates a temporal directory
 
 The directory is automatically deleted when bashunit completes.
 
-## is_command_available
+## bashunit::is_command_available
 
-> `is_command_available`: Checks if command is available
+> `bashunit::is_command_available`: Checks if command is available

docs/skipping-incomplete.md

@@ -3,8 +3,8 @@
 There may be various scenarios where the "passed" and "failed" outcomes for a test are not sufficient.
 To address these situations, the following functions are available for your use.
 
-## skip
-> `skip "[reason]"`
+## bashunit::skip
+> `bashunit::skip "[reason]"`
 
 Not all tests can be run in every environment; when such situations arise, you can mark a test as skipped.
 
@@ -17,15 +17,15 @@ however, it will indicate that some tests were skipped in the final output.
 ```bash [Example]
 function test_skipped() {
   if [[ $OS != "GEOS" ]]; then
-    skip && return
+    bashunit::skip && return
   fi
 
   assert_empty "not reached"
 }
 
 function test_skipped_with_reason() {
   if [[ $OS != "GEOS" ]]; then
-    skip "Not running under Commodore" && return
+    bashunit::skip "Not running under Commodore" && return
   fi
 
   assert_empty "not reached"
@@ -42,8 +42,8 @@ Some tests skipped
 ```
 :::
 
-## todo
-> `todo "[pending]"`
+## bashunit::todo
+> `bashunit::todo "[pending]"`
 
 You may come up with a test that you'd like to implement later.
 Instead of leaving the test implementation empty —which would mark the test as complete— you can flag it as incomplete.
@@ -56,11 +56,11 @@ however, it will indicate that some tests were incomplete in the final output.
 ::: code-group
 ```bash [Example]
 function test_incomplete() {
-  todo
+  bashunit::todo
 }
 
 function test_incomplete_with_pending_details() {
-  todo "Detailed description of what needs to be done"
+  bashunit::todo "Detailed description of what needs to be done"
 }
 ```
 ```[Output]