问题标签 [testability]

TL;DR： 在 MVVM 客户端中实现 ViewModel 和 WCF 服务之间的依赖关系的良好且可测试的方法是什么？

请阅读问题的其余部分，以获取有关我在尝试执行此操作时遇到的问题的更多详细信息：

我正在开发一个连接到 wcf 服务的 silverlight 客户端，我想为客户端编写单元测试。因此，我正在寻找在我的 ViewModel 中使用 wcf 客户端并测试该交互的良好解决方案。到目前为止，我已经找到了两种解决方案：

解决方案1：这实际上是我到目前为止的实现方式：

好的部分：它相对容易模拟

不好的部分： 我的服务客户端和我的 ViewModel 一样长，当我有并发请求时，我不知道哪个答案属于哪个请求。

解决方案 2：受此答案 WCF Service Client Lifetime的启发。

好的部分：每个请求都在不同的客户端上，因此将请求与答案匹配不会再有问题。

不好的部分：测试更难。我每次都必须为工厂和 wcf 客户端编写模拟。这不是我想做的事情，因为我已经有 200 次测试...... :(

所以我的问题是，你们是怎么做到的？您的 ViewModel 如何与 wcf 服务通信，在哪里注入依赖项，以及如何测试该交互？我觉得我错过了什么。。

我正在寻找一个示例来说明测试静态类与实例类时的困难。有人可以提供一个吗？

我正在研究一个面向对象的设计问题。我将尝试专注于我感到困惑的部分，并用文字解释它，而不是提供代码。

I have a class called SalesPolicy that contains a List of TaxPolicy. TaxPolicy is an abstract class that represents a tax policy with name and tax rate as attributes. TaxPolicy contains an abstract method called accept. Concrete implementations of a TaxPolicy must implement the accept method and provide the logic for deciding when a TaxPolicy is applicable.

I have another class called SalesEngine. SalesEngine has a SalesPolicy and SalesPolicy is one of the parameters to the SalesEngine constructor. SalesEngine decides whether a TaxPolicy from a List of TaxPolicy in SalesPolicy is applicable for an item or not by calling the accept method and then calculates the tax accordingly. As explained earlier, SalesPolicy contains a single attribute which is a list of TaxPolicy and a method to add to the List.

我需要知道的是是否可以为 SalesEngine 类设置像 SalesPolicy 这样的参数。从可测试代码的角度来看，这有什么影响？

我必须编写看起来像这样的代码（当然要复杂得多）：

我的问题是：是否有任何技术可以使此类代码可测试？我不认为编写测试像：

是最好的主意。如何在不调用系统函数的情况下测试 stopThread() 函数？有什么方法可以模拟 pthread_create 吗？

我正在检查我们应用程序的单元测试并改进/添加更多单元测试。我在单元测试/测试驱动开发方面相当（不，非常）新手，我找到了我想测试的以下方法。我被卡住了，我的问题是是否有办法重写它以使其可测试？

假设我们有一个使用终端程序转换将图像转换为另一种格式的函数。这是代码：

现在我想测试这个函数以验证它是否按预期工作。

最直接的方法可能是只进行单元测试，提供真实图像的路径，并验证是否使用正确的扩展名创建了新图像。但问题是，很难知道创建的图像是否实际上是在质量设置为正确值的情况下创建的，并且在测试函数中实际转换真实图像有点尴尬。

如果我这样调用函数：

我现在真正感兴趣的是它从此输入将此数组作为输入发送到 check_call：

如果是这样，那么我知道该函数正在针对这种特殊情况做正确的事情。

因此，如果用于测试目的的函数在我测试时实际上只返回这个数组，并且只在我运行真实程序时转换图像，那将是很方便的。

但是在所有函数中都有 if 语句来告诉函数为测试做不同的事情可能不是很好我的测试代码没有检测到。

我正在寻找有关如何测试此代码或如何重构它以使其更具可测试性的建议/讨论/提示。我对使用 python 转换图像的更好方法不感兴趣，这个问题纯粹是关于代码可测试性。

所以，如果你可以测试这个功能——你会怎么做？

我问这个问题是因为我相信他们这样做是有充分理由的，而且大多数人没有正确使用它，无论如何，从我迄今为止的行业经验来看。但如果我的理论是正确的，那么我不确定他们为什么包含私有访问修饰符......？

我相信，如果正确使用默认访问，它可以在保持封装的同时提供增强的可测试性。它还使私有访问修饰符变得多余。

默认访问修饰符可用于通过对需要对世界其他地方隐藏的方法使用独特的包来提供相同的效果，并且它在不影响可测试性的情况下做到这一点，因为测试文件夹中的包具有相同的能够访问源文件夹中声明的所有默认方法。

我相信这就是 Java 使用包访问作为“默认”的原因。但我不确定为什么它们还包括私人访问，我确定有一个有效的用例......

我是测试新手。当我开发我的应用程序时，我使用 Robotium 来测试我的应用程序，但现在，我想测试一些属于我的 Util 类的函数。例如：

或者例如：

我该如何测试这些功能？

非常感谢！！

假设有使用 MVVM 轻工具包的 WPF 应用程序。

这个工具包的一个很好的例子是定位器。很棒的是它包含 SimpleIoC，它使我们能够注册服务并成为接口驱动。

有时 Locator 构造函数可以真正增长。不幸的是，除了注册接口之外，它还包含一些逻辑：

这只是一个例子——如果我在定位器构造器中需要更多逻辑怎么办。也许我的服务架构是错误地创建的，因为它们不是独立的，或者在这种情况下，我应该放弃使用定位器 - 但是我会失去 DI。

另一件事是，在少数 ViewModel 中有对 Locator.GetInstance 的引用，我发现另一个不是一个好的做法，因为它应该通过构造函数注入以启用可测试性。

另一个方面是正确使用 AvalonDock。

AvalonDock 是一个很棒的可锚定控件，它可以准备应用程序，这些应用程序可能类似于具有可锚定、可停靠窗格的 Visual Studio 等应用程序。

这个窗格实际上是另一个通过属性绑定到 AvalonDock 的 ViewModel。

MainViewModel 具有属性 Tools = new Tools[] { ViewModel1, ViewModel2}

但是每个 ViewModel 都在 Locator 中注册。

因此我在 MainViewModel 中使用（违反 DRY）它们作为

属性获取器：Locator.GetInstance()

在我看来，这是另一个不好的例子——甚至不安全。如果 Avalon Tool ViewModel1 所需的任何服务尚未注册但在 MainViewModel 实例化期间通过 getter 调用，该怎么办。

开始不匹配了。你有什么好的做法吗？

我发现了许多示例，例如 Workspaces (MainViewModel)，但没有人同时使用我发现非常有用的定位器。

我想保留 Locator，因为我认为它是一件好事，它使 mme 能够通过依赖注入和接口驱动来测试我的项目。

任何想法建议？我会很感激的。

我用 Java 开发了很多代码，并涉足了 Groovy 和 Haskell，这让我现在转向了 Scala。

我对 Scala 的功能方面感觉比较舒服，但我发现自己在 Scala 中的面向对象设计上有点摇摆不定，因为它感觉与 Java 有点不同，特别是由于特征/混合。

我的目标是编写尽可能可测试的代码，这在我的 Java 开发中一直转化为专注于

• 尽可能的不变性
• 更喜欢由构造函数注入状态
• 总是选择组合而不是继承（受此帖子的严重影响，并且可能对 SO 上的帖子反应过度）

现在我正试图在这个新的 Scala 领域站稳脚跟，我很难弄清楚我应该在这里采用什么方法，特别是我是否应该开始出于某些目的使用继承。

Scala 编程（Wampler 和 Payne；O'Reilly，第 2 版）有一个考虑因素的部分（“良好的面向对象设计：题外话”），我已经阅读了一些关于 SO 的帖子，但我还没有看到明确提及可测试性的设计考虑。这本书提供了关于使用继承的建议：

1. 抽象基类或特征由具体类（包括案例类）子类化一层。
2. 具体类永远不会被子类化，除了两种情况：
   • 混合在特征中定义的其他行为的类 (...)
   • 仅测试版本以促进自动化单元测试。
3. 当子类化似乎是正确的方法时，请考虑将行为划分为特征并混合这些特征。
4. 永远不要跨父子类型边界拆分逻辑状态。

对 SO 的一些挖掘还表明，有时 mix-ins 比 composition 更可取。

所以本质上我有两个问题：

1. 是否存在使用继承更好的常见情况，即使考虑到可测试性？

2. 混入是否提供了增强代码可测试性的好方法？