The other replies have probably given more than enough to address the issue of unshifting data to STDIN, but there were a couple things about your original example pseudo-code that puzzled me:

# old STDIN: 1 2 3
while (<STDIN>) {
   if (some condition) unshift "hi test test" to STDIN
   # new STDIN hi test test 1 2 3 
}
[download]

First: to produce the result that you say you want, you would need to unshift "hi test test $_", wouldn't you?

Second: why go to the trouble of doing deep magic with the file handle? That is, why wouldn't the following approach, which yields the same basic result, do just as well (with a lot less code and complexity)?

while (<STDIN>) {
    if (some condition) $_ = "hi test test " . $_;
    # ...
}
[download]

If the problem is that some other branch in the while loop is looking for "hi test test " to trigger some action, it would seem easy enough to arrange the logic so that this other branch will execute on the same iteration after the prefix has been added.

If it's more complicated then that, maybe you should be looking at a two-stage process, where the first stage is a simple text filter, adding prefixes to lines where needed, etc; the filter's output is piped to the second stage, whose logic is now much simpler, because the stream is appropriate to its task -- two simple scripts are often better than one complicated script. If you want to keep it really simple for the command-line user, you could set up the second script to handle its input like this:

# supposing that @ARGV contains file name(s) to be filtered and proces
+sed:

open( INP, "my_filter_script.pl @ARGV |" ) or die "can't filter: $!";

while (<INP>) {
    # prefixes and other source code filtering are already done
    # ...
}
[download]