A nonexistent test path reports 'No tests found', same as an empty one #1263

Observation

A path that does not exist and a path that exists with no tests produce the identical result:

$ bashunit /nonexistent/path.sh
 No tests found        (exit 1)

$ bashunit emptydir/
 No tests found        (exit 1)

So bashunit tsets/ — a typo — reads as "your tests did not match", and the natural next move is to check test naming, filters or the discovery glob rather than the path.

Why I am proposing rather than fixing

The shared message looks deliberate. src/main/run.sh says so:

reaching zero files here is a real answer, so it renders "No tests found" and exits 1, the same shape an empty shard has, instead of the guard's "path is required" help dump

and --changed, --shard and --filter all converge on it on purpose. #1199 aligned bench with the same convention. Distinguishing "path does not exist" from "path has no tests" is a design change to that convention, not a bug fix, so it seems worth your call rather than mine.

If wanted

The narrow version keeps the convention intact: an argument that does not exist on disk is a wrong invocation rather than an empty selection, so it could say so before discovery runs, leaving every genuinely-empty case (--filter matching nothing, an empty shard, --changed with no changes, a directory with no test files) exactly as it is today.

That boundary is the whole question: an empty result is a real answer, a missing path is a typo.