小编geo*_*off的帖子

在阅读了一篇博客文章,提到为了便于测试而揭露公众获取者似乎是错误的,我找不到任何更好的实践的具体例子.

假设我们有这个简单的例子:

public class ProductNameList
{
    private IList<string> _products;
    public void AddProductName(string productName)
    {
        _products.Add(productName);
    }
}

让我们说出于面向对象设计的原因,我没有必要公开公开产品列表.那么我怎样才能测试AddProductName()是否完成了它的工作？(也许它添加了两次产品,或者根本没有.)

一种解决方案是公开_products的只读版本,我可以测试它是否只有一个产品名称 - 我传递给AddProductName()的产品名称.

我之前提到的博客文章说它更多的是关于交互(即产品名称是否被添加)而不是状态.然而,状态正是我正在检查的.我已经知道AddProductName()已被调用 - 我想测试该方法完成其工作后对象的状态是否正确.

免责声明:虽然这个问题类似于 平衡设计原则:单元测试,(1)语言不同(C#而不是Java),(2)这个问题有示例代码,(3)我不觉得问题是充分回答(即代码可以帮助证明这个概念).

我开始为一个非常大的Visual Studio解决方案开发和组织测试.(是的,我知道测试应该与代码一起开发,而不是在项目接近完成时开发,但事情就是它们.)

我在Visual Studio解决方案中看到了有关组织单元测试的类似问题,但我也没有看到任何地址集成测试.我希望得到关于在何处放置测试项目的一些指导,以便它们不会混乱已经很大的代码库.

这是解决方案中基本的事物层次结构.(所有未以.proj结尾的项目都是项目或解决方案文件夹中的文件夹.)

• HardwareServices
  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
  • HardwareService2
    • HardwareService2.Core.proj
    • HardwareService2.Host.proj
    • HardwareService2.Service.proj
• 基础设施
  • MyApp.Database.proj
  • MyApp.Infrastructure.proj
  • MyApp.ReportViewer.proj
  • MyApp.SettingsManager.proj
• AppModules
  • AppModule1.proj
    • 共同
    • 报告
    • 服务
    • 的ViewModels
    • 查看
  • AppModule2.proj(与其他AppModules类似的结构)
  • AppModule3.proj(与其他AppModules类似的结构)
• 模块
  • ComputeEngine.proj
  • Footer.proj
  • Header.proj
  • CommonServices.proj

我的想法是创建一个名为"Tests"的解决方案文件夹,然后模仿上面的层次结构,为每个生产代码项目制作一个测试项目.在每个测试项目中,我将创建名为"UnitTests"和"IntegrationTests"的文件夹.

我的重点是建立一个统一的命名/组织方案,以便有没有什么地方新的考验应该去哪里可以找到现有的测试歧义.由于大尺寸项目/应用的,我想获得的结构非常稳固出了大门,使得它不是一个痛苦之后.

感谢您的时间和建议.