the (undocumented!) nomenclature used is that do_ implies that the method creates one or more test steps that accomplish whatever is requested.  expect_ means that expectations are generated but it's assumed that we're already living inside a test step.  _expect_ is the same but implies tests should never directly call it.

To integrate with other logic, generally, either:
* functions may be passed that will be invoked inside the test step.  Usually this takes the form of a function that can help add additional test expectations rather than a function that would have the body get passed in.  The rationale is that we usually want our test steps to be as small as possible so that when you expand them you're not looking at several pages of logs.  (When we have the several pages of logs, it's usually because it's hard to break things into smaller steps in a way that won't have events randomly sliding between other steps.)
* a testThing is created that is returned by the helper call.  so do_waitForBodyReps would create a testThing that it would set .bodyInfo on during the execution of the step.  Then in a subsequent step, like T.check('investigate the body') you could run some more complicate logic, etc.  This also can help out with life-cycle stuff, because then there might also be do_killBody(testBody) that would run a step that calls the die() method on the body.  This is more meaningful for slices where lots of things happen when killing the body and the process is async.

For the first thing, if what you're doing with the body is pretty simple, I think having us do: do_viewBody(header, { expectFunc, withMEssage }) is probably a good way to go.  And just like we have do_viewFolder (which opens a slice and kills it in the same step) and do_openFolderView/do_closeFolderView for longer lived things, we could do the fancier second option later.

I think in this case, do_viewBody or do_getBody is a better name.  I assume you derived your name from do_waitForMessage, but the "wait" there is because we are really waiting for a message to show up in an inbox which is an asynchronous process completely out of our control with no corresponding API call.  Whereas the semantics of getBody potentially having to do an online operation are well-defined in our API (whether or not they are documented ;).