Service Studio should have new, separate "Tests" tab.
This would enable integrating tests to any eSpace and would minimize required overhead for testing any action, including private actions.
Why?
- Testing your code is more professional than not testing.
- Unit testing should be minimal extra effort for developer, because otherwise tests are usually not done.
- Publishing new code could be controlled - you cannot publish untested code, or code which has some failing tests, for example.
- Test code should never go to Production environment.
- Testing is good.
How?
- Tests are integrated to eSpace/module oml file.
- During code generation process, actions from "Tests" tab would create a separate .NET project and this project would be a friend assembly (internalsVisibleTo attributes configured) for main project to compile.
- 1-Click Publish deployments with tests could start from (currently underused?) personal area (or another IIS folder), where tests would be run.
- Depending on how tests go and how is decided in additional configuration, deployment would continue to Public area or show an error in Service studio.
This way, creating unit tests would be as effortless as when creating unit tests in any other modern programming language - just few clicks away. There could be also accelerators to generate unit test actions or "system events" to initialize/teardown test runs.
Currently, writing any tests to private actions is also either impossible or exposing some unwanted/test related code to production environments.
It's a big change, but from discussions with makers/experts @ ODC I've learned this should not be too far-fetched idea to implement. Maybe for P12, please?
Another, possibly the simplest way to enable testing / production code separation without massive modifications to existing compiling process could be a capability to define another espace as "friend" espace. This per-espace setting could reveal internal (=OS private) actions to the another espace marked as a friend and thus enable referencing these otherwise out-of-the scope actions for testing purposes.
If done like this, feature could be achieved using small amounts of .NET reflection trickery or previously suggested InternalsVisibleTo attribute (that has been around since 2002 release of .NET 2.0).
Security-wise, there should be no problems either, (albeit a bit more work during compilation) as friend assemblies can be defined as signed assemblies, too.
Personal opinion, but this topic is really heavily connected with OS small book #2, #5 and #7.