JavaScript...what到单元测试

Question

我想听听其他人对JavaScript中单元测试的看法。我一直在考虑这个问题，并做了一些实验，让我展示我认为是正确的事情。首先，为了能够对生产代码进行单元测试，需要将productin代码划分为三个层：(1) DOM/jQuery、(2) Logic和(3) AJAX。请参阅附件中的图像。

逻辑层位于DOM/jQuery层和AJAX层之间，也就是说，DOM/jQuery层不绑定到AJAX层。因此，在我看来，唯一需要进行单元测试的层是逻辑层。编写单元测试应该很容易，否则程序员就不会编写它们。为DOM/jQuery层编写单元测试的用途是什么?好的，您已经在ul元素中添加了安莉元素，为什么我需要断言，应该没有if语句。关于AJAX层，assert...the URL中使用的是"blah"，我知道它是"blah“。无论在AJAX层中获得的数据如何，都应该提供给逻辑层。现在，逻辑层是一个不同的故事，例如，在单元测试中，可以给出可能来自AJAX调用的数据，并使用模拟DOM/jQuery层来验证数据是否正确显示。让我知道你的想法。

Answer 1

为什么不Ajax?

我觉得这是一个很好的单元测试的地方。作为一个进出给定域的入口/出口点，这是一个瓶颈点，很高兴知道您的代码将以最好的方式处理坏数据。理想情况下，网络问题或数据问题不会抛出破坏页面上所有代码并酌情提供用户反馈的异常类型。但我首先要强调的是，实时日志验证是一种策略。

半协议的DOM接口

当所有HTML都正确时，您所能测试的就是某些内容是否有效。当HTML被破坏时，您真的不能假设您的代码应该做什么，因为对每一个小DOM操作进行验证都太昂贵了。而且，破坏通常是如此明显，无论如何，这都是一种浪费。更好的做法是让测试页面在功能齐全的小部件上充满在生产中的变化，并自动激活它们的各种功能。如果这算作单元测试，那么我想我不同意。

Data-Juggling/Data-Formatting/Logic单元测试

协议这绝对是最有意义的内部层，集中在某种测试策略上。

，但仍未100%在广泛的客户端网络单元测试

上销售。

我对此持怀疑态度，主要是因为在提交代码之前测试代码非常容易，而且客户端的问题通常是高度可见的。如果您没有得到即时的视觉提示，您将看到问题的控制台。

IMO，关键是集中于测试您的代码如何对来自您无法控制的向量中的有害内容作出反应，比如服务器在页面加载时从Ajax或JSON传入的内容。任何客户端web开发人员都不愿意在任何客户端开发人员在其他地方破坏错误的错误类型的回归问题。首先，通过保持关注点的清晰分离和在每个浏览器支持的所有工作中手工测试，在提交之前，任何客户端开发人员都不愿意允许它们进入他们的代码。这需要时间，我认为，与其测试是否未能避免问题，不如一开始就将时间用于避免问题。JS的灵活性使得降低复杂性变得非常容易，因此我倾向于只在关键瓶颈和高度复杂的数据处理方面进行自动化测试。

在最近的一项工作中，一个非常混乱的代码库--客户端开发人员几乎没有碰过它--是最关键的调试时间节省器IMO，它首先建立了一种非常快速地排除它是否实际上是客户端问题的方法。如果您正在验证服务器之间的所有数据，以及记录问题(当然是在生产中静默地)，这可能是几秒钟而不是几个小时的问题。但这当然不是单元测试，而是验证，我认为这比单元测试更重要，因为您可以像使用客户端web代码一样在活动环境中轻松地运行和诊断代码。

考虑混合策略

所以我不是说这总是个坏主意。我只是认为，JavaScript擅长于它擅长的东西，而客户端web上的开发正是它独特的动物，所以最好花时间避免不必要的复杂性，这种复杂性首先会让人担心回归问题，而更多的是帮助快速诊断运行环境中的问题。小部件测试-页面很棒。数据输入/输出的验证以及故障处理的单元测试都是很棒的。当处理数据处理/格式化的高度复杂性时，单元测试也可能是很棒的。但我认为，任何给定层的100%单元测试覆盖范围，可能更好地集中在其他地方，用于典型的客户端web应用程序。

Answer 2

在接口上进行最低限度的测试。在您的关系图上，您应该有两个箭头，一个在jQuery2000Logic，另一个在。

随着设计的巩固，你要向内工作。您不想花费大量的时间，单元测试一些内部逻辑，这只会被撕开，然后被其他的东西取代。

当然，当你给你的设计造粒时，逻辑盒看起来会像很多小盒子或条纹。再次在组件之间的接口上进行测试。