MVC模式的另一个方面，是使得开发人员可以对传统意义上无法进行测试的UI部分进行单元测试。Chad描述了微软是如何实现这一点的：

  微软在最近对MVC框架的更新中（Beta，RC和最终的发布版）迈出了一大步，相比于Preview 3，对单元测试的支持更好了。但是我仍然认为继承和防备代码的过度使用以及故意不使用接口，使得在ASP.NET MVC中进行测试显得很笨重。

  他继续解释了FubuMVC是如何实现这一模式的：

  相反，FubuMVC使用简洁的、易于mock的接口，着重于高内聚低耦合的设计。其中，低耦合更成功一些，但这一切仍在开发之中，我希望将来的设计可以提高内聚程度。

  FubuMVC高度依赖SOLID原则，这使得它有很高的灵活性，开发人员仅仅使用一个mock就可以替换框架中的整套部件，并且可以使用任何他们喜欢的mock框架。

  FubuMVC并没有很多的防御性代码……相反，它将注意力集中在设计提供自由控制的组件上面，这些组建是客户代码主要存在的地方：控制器（controller）、行为、视图（view）以及可以重载的部分。

  FubuMVC的类之间几乎没有依赖关系，仅有的依赖也是对接口的依赖，这些接口可以很容易的用mock对象来模拟。

  由于项目中有Jeremy（IoC容器StructureMap的创建者），你可能会认为控制反转和IoC容器会得到较多的支持，事实上也确实如此：

  目前的版本仅支持StructureMap，但是将来很可能会加入对其他容器的支持。框架对于容器的使用非常少，仅限于在配置时使用。其余的部分利用容器的自动绑定功能完成，因此基本上没有使用“service location”。对于仅有的一点service location，我们使用微软Patterns and Practices的Common Service Locator进行处理，它可以让我们方便的替换底层依附于CSL模式的IoC容器（多数容器都满足这个条件）。

  FubuMVC还有一个contrib project，相比于FubuMVC的核心框架，这个项目的目标有什么不同:

  我们希望能够有更多的自由来发展FubuMVC，因此建立了FubuMVC Contrib。我们想尝试一下插件，这样可以有更多的人参与进来，他们可以在较少的限制下做更多的尝试，同时保持核心框架的稳定。

  FubuMVC核心框架将会维持少数几个成员，对待补丁会更谨慎，对框架的修改也会更少。FubuMVC-Contrib将会有更多的参与者、更多的改动、更低的要求，可能有无法工作的代码或实验性质的代码。当在contrib中开发出有趣的东西后，可以将这些东西合并到核心框架，或者拆分到单独的项目中。

  现今，FubuMVC还没有ASP.NET MVC那样成熟，但是它的实现方式很有趣，这个框架将会如何发展，它与ASP.NET MVC的发展方向将会有怎样的不同，我们将拭目以待。关于FubuMVC的更多信息，可以查看他们的wiki和Ryan Kelley的从头开始学FubuMVC教程。