Simple UI testing is easy enough in ASP.NET MVC. Essentially all you have to do is assert that the returned HTML contains the elements you need. While this ensures that the HTML page is structured the way you expect, it doesn't fully test the UI.
Proper web UI testing requires a tool like Selenium that will use browsers on your machine and ensure that the JavaScript and HTML are working properly in all browsers. Selenium does have a client/server model so that you can have a set of virtual machines with Unix, Mac, and Windows clients and the set of browsers common to those environements.
Now, a well designed MVC (pattern, not framework) application puts the important logic in the models and controllers. In short, the functionality of the application is tested when you test those two aspects. Views tend to only have display logic and are easily checked with visual inspection. Due to the thin processing in the view and the bulk of the application being well tested, many people don't think that the pain of testing the view layer outweighs the benefit gained by it.
That said, MVC does have some nice facilities to check the DOM returned by the request. That reduces the pain quite a bit for testing the view layer.
I want to introduce the concept of unit tests (and testing in general) to my co-workers
I think it might be better to start from the practical, not the conceptual, side. Of course, if you find during casual discussion that your coworkers and/or management are interested to hear about unit testing, all the better - then you may google up some concrete experiences / evidence from the web, put together a brief training, etc. However, from what you describe, it sounds like your teammates aren't very open to this strange new idea.
In such a situation, I would just start writing my little unit tests without trying to explain too much to anyone first. Add a couple of them whenever I change code, without trying to thoroughly cover all the code (which would take an inordinate amount of time). Ideally, if I manage to strike a fine balance, by the time they notice I am writing unit tests, I may already have a substantial test suite, and some concrete results to show (like "with this test case I managed to catch a bug introduced by last week's change, which would have otherwise slipped through to QA/production"). That will prove the tests' worth to any serious developer.
After that, I am in a good position to start explaining the long term benefits of unit testing, like
- it proves that the code works - anytime, anywhere, instantly and automatically, which in turn
- gives confidence to refactor, resulting in improved design and better maintainability,
- and if something gets broken, unit tests give you (almost) instant feedback, as opposed to several days' or weeks' latency if the bug is caught by a separate QA department. Which usually enables you to fix the bug in seconds, instead of debugging for hours/days, in code which has long since dropped from your short term memory.
See also this related thread: Automated unit testing, integration testing or acceptance testing.
And an earlier one from SO: What is unit testing?
Best Answer
Dependency injection is one way of handling this. You can set-up a test database to mimic the shopping cart, or you can even write some code that "confirms" the customer's transaction. Then at runtime, your software will pick which component to connect to.
Just don't connect to the production database for anything during testing!