I'm a developer who is making his first attempts at using Selenium for automated UI testing. What is the best practice for creating and naming test classes in an MVC webapp?
My webapp has a dozen controllers:
Should I be creating a dozen test classes, one for each controller:
Or is there a better way to organize my tests?
I wouldn't say that MVC architecture implies some specific structure of UI tests.
In web applications the controllers are usually the components which process requests from the client. Those controllers are not necessarily related to any solid feature but they might serve for many features simultaneously (for example the controller that processes AJAX calls from your pages). You also can have a controller that dispatches the calls to other controllers which would make the test structure even more complicated.
I would treat MVC as a solid architecture where M does not make sense without V and they both would not have much value without C. Neither of those three have bigger value than the others. They might also have complex many-to-many relationships.
So if you are asking about Selenium (which is basically a tool for black-box testing) tests (not the unit tests) you should not rely on how exactly M, V and C are implemented and structured. (However your idea about structuring your tests in the line with your controller classes might work well for API tests)
For Selenium tests I would start from analyzing how your features are organized and how your user interface is organized and would structure the tests classes in the way relevant to typical user paths. This would let you apply inheritance mechanisms that would make your classes effective from coding standpoint.
The main purpose UI tests is to validate the application functionality with respect to the UI. Hence, the underlying architecture or implementation does not matter. So your test classes you should be organised around various features related to Vendors, Invoices, Orders, etc. For example, you might have various test classes as OrderHistory, OrderPlacement, InvoiceGeneration, etc. This way your tests will be more tied with your expected application functionality, rather than the actual application implementation (which is under the scanner), hence leading to better software testing solutions.
