Q:

Naming Models vs. MonoBehaviours

I recently ran into the problem where you can't instantiate MonoBehaviours in unit tests, so I'm going through the process of moving all of my non Unity-related code (code which doesn't access any MonoBehaviour fields/methods) into separate model classes, which are then used in the corresponding MonoBehaviour class.   However, all of the Unity examples that I've seen have all the code associated with a given game object in a MonoBehaviour class.   For instance, an orc in the game has its code in an Orc class, which is derived from MonoBehaviour.   So I'm struggling with naming my classes when I separate the single Orc MonoBehaviour class into an orc model and an orc MonoBehaviour.   Is there a best practice guideline to follow when naming MonoBehaviour classes versus naming the corresponding model class? 

A:

Games just like any other applications can run tests.  If test was useless in games, Unity would not have spent hours developing a tool.  
Just like any other applications, some parts cannot be tested like input that rely on the framework.  In Unity, all the methods about the engine like Update, Collision and else cannot be tested but they can be faked. 
Other case in Unity is MonoBehaviour but you can bypass that easily following that blog post:
http://blogs.unity3d.com/2014/07/28/unit-testing-at-the-speed-of-light-with-unity-test-tools/
Basically, the MB class gets all the Unity related actions and callbacks.  The logic that needs to be tested goes in a custom class. 
As for the naming you can use XXXXController (MB) and XXXContainer (non MB). 
In your test, you focus on testing the XXXContainer that contains all the logic.