There are several alternate ways to structure that code fragment. If you already have %HASH primed to contain keys for the values you're trying to match,

  if (exists $HASH{$s}) {
    my $foo = $HASH{$s};
    ...
[download]

which lets you write a unit test against the initialization of %HASH, in addition to a smaller number of tests of foo(). The risk of that approach is that the link between %HASH and its use in foo() is tenuous from the perspective of the tests. (I.e., how can you prove, via tests, that there's any association between %HASH and the behavior of foo()?)

Another approach is to move the matching into a separate sub, which lets you write more focused unit tests against the matching subroutine, but which still leaves you with the tenuous link problem.

One approach to establishing linkage is to use Test::Resub to temporarily replace the search subroutine with a test-only version that records that it has been invoked, and then write a test against foo() to verify the invocation. (We used to call these "plumbing" tests, since their goal is to verify that A calls B without asserting anything about the behavior of B, leaving assertions about B's behavior for other tests.)