At first blush, it seemed rather simple. The majority of my tests were simple things, "ok($foo=~/bar/)" which you could easily translate to english (or keep in english, if you're thinking that way). Simply: $foo should contain bar. and you have an english statement that does the same thing as perl.
Instead of using English, I'd take advantage of the most appropriate test function and use a test name for clarity. So your example could be written:
like( $foo, qr/bar/, 'foo contains bar' )
At the moment I can think of no real way to translate between all of the high level assumptions we make when we're describing the project specification, sense so many of these are context sensitive in various ways, I would need a English->Perl translator, which would probably put programmers out of a job if such a thing could actually be written. Anyone else have any ideas on describing the project spec in a higher level / more natural language but still being able to be used as a test?
You can always use Perl to make higher-level tests. I'm always writing little subroutines in test suites that capture a higher level testing concept.
Can you give an example of a higher level requirement that you think might be problematic?