Jumping off some email conversations I've had with Ryan I wanted to get some feedback and possibly suggest some module structure ideas and a pattern for implementing tests for Drupal Commerce.

With regards to the structure of the module a common practice I try to follow is to distinguish between public and private APIs. All code will follow this to a certain extent, but it may make sense to make it a part of the standard for the module to have a clearly defined public API and then an API that is private and meant to be consumed only by the methods making up the PUblic API.

Now, the reason this is meaningful for testing is that you can start writing tests for the public API and by virtue of the the module's structure you are covering the various parts of the private API in doing so. This also makes your public API test suite more like integration tests since they are testing integrated behaviors rather than granular functions. Then you can drill down to the private API to write more granular unit tests.

Another thing to note is that any tests should not focus on the implementation specifics but on the behavior expected of the function being tested. Basically treat functions like black boxes. What matters is that when you plug something in you get what you expect back out, the how is not important, at least it shouldn't be. Too many function tests end up dealing with implementations which makes it impossible to use the tests as a regression suite.

Anyways, this is an area that probably needs to be talked about in detail, so lets bounce this stuff around.