5

我正在尝试对一个相当复杂但使用 MVC 的应用程序进行回顾性单元测试。我知道追溯应用单元测试并不理想，但我仍然相信通过重构现有代码是可能的。大多数情况下，如果不依赖其他单元，就不可能对一个单元进行单元测试，即视图依赖于模型。

在这种情况下进行单元测试的最佳方法是什么？使用真实模型还是创建模拟模型更好？

在我的情况下使用真实模型的问题在于该模型依赖于从 XML 获取数据的其他响应类，因此存在依赖链。这个模型有很多数据，所以使用它会容易得多，但也许我错过了重点。

为简洁起见，我提供了应用程序的 UML。

在此处输入图像描述

**编辑 ****

好的，如果我是正确的，在模拟类中创建模拟数据是最佳实践吗？例如，我有一个模拟类“MockPlaylistPanelModel”，它创建视图类“PlaylistPanel”运行而没有错误所需的数据：

class MockPlaylistPanelModel extends Mock implements IPlaylistPanelModel
{
  /** 
   * Return all playlist items
   * @public 
   */
  public function get mainPlaylistItems():Vector.<PlaylistData> 
  {
    var playData:Vector.<PlaylistData> = new Vector.<PlaylistData>;
    var playlistResp:PlaylistData = new PlaylistData(0, "", "", 0, 0, 0, 0);
    playData.push(playlistResp);
    return playData;
   }

}
4

3 回答 3

6

为了将单元测试回溯到现有应用程序中，您通常需要更改应用程序代码以支持单元测试（正如您正确提到的，您可能需要执行一些重构）。但是，当然这里的风险是应用程序的更改会引入错误，如果没有进行一些测试，就无法避免这些错误。

因此，一个明智的方法是进行一些系统级测试，涵盖您的一些关键用例。这充当了一种围绕您的应用程序的“测试脚手架”，这意味着您可以更安全地开始引入较低级别的测试，并在您修改应用程序以使其更具可测试性时降低引入错误的风险。一旦这到位，您就可以引入一项政策，即开发人员必须在更改之前围绕他们更改的任何代码编写测试 - 这允许您围绕应用程序有机地发展一组自动化测试。

我强烈推荐阅读《有效地使用遗留代码》 ——这本优秀的书涵盖了将测试引入到几乎没有自动化测试的现有应用程序中的各种有用技术。

关于您是否应该在模拟类中创建模拟数据以进行测试的问题，这是您在注入对象的测试版本时可以采用的一种方法，但可能不是最好的。通过使用像Mockito这样的模拟框架，您可以轻松地动态创建具有明确定义的行为的模拟对象。在您的情况下，您可以使用 Mockito 创建一个模拟模型实现，然后将您的模拟模型注入到任何依赖它的对象中。

于 2013-07-19T11:13:28.610 回答
0

它们不是单元测试；它们是集成测试。

是的，使用模拟来隔离单元测试的类。

于 2013-07-19T09:41:53.997 回答
0

单元测试必须只测试程序的一部分。如果您使用其他部分，它将成为集成测试。

集成测试检查各部分是否可以很好地协同工作，而不是做他们必须做的事情。

单元测试检查部件是否完成了它必须做的事情。

那就是两次测试的区别。

要重构单元测试，您可以寻找设计模式依赖注入。

于 2013-07-19T10:59:57.393 回答