【问题标题】:Testing for classfier with examples用示例测试分类器
【发布时间】:2011-10-27 10:22:59
【问题描述】:

我正在编写一个分类器,用于对餐厅/酒店/等的特价商品进行分类...这是用于分析外部网站的网络爬虫的一部分。 首先我做了一顿饭?() 方法,它接受一段文本,如果它认为文本是关于一顿饭的,它将返回 true。它不可能 100% 准确,因为只使用了简单的关键字匹配。

def meal?(text)
  !text.match(/restaurant|meal|wine|.../i).nil?
end

现在我正在为它写一个测试,我有两个问题。第一个是我认为在单元测试中重新列出所有这些关键字有点多余。你怎么看?

第二个问题: 我在源代码管理中有一个 .html 文件。它用于测试爬虫的解析功能。理论上它的所有项目都应该通过,所以我正在考虑在这个分类测试中使用那个 html,解析那个 html 并将每个交易的描述输入到这个方法中。

一个缺点是 .html 来自外部站点。当该站点更改布局时,我将更新此 .html 文件,然后我也必须更改此分类测试。不过我觉得还可以。

这是推荐的吗?我之所以想到这种方式,是因为我觉得从那个 .html 中提取信息并将其放入测试脚本本身(不是 DRY,并且使测试脚本相当大)中感到不安。提供解析后的描述是否会违反任何基本的测试法则,例如“这会向开发人员隐藏必要的细节”或“这对生成报告不利”?

【问题讨论】:

    标签: unit-testing testing


    【解决方案1】:

    好的,所以我显然误解了这个问题,所以我将完全修改这个答案。

    我个人认为从 html 文件中获取实际文本并将其复制/粘贴到测试中比间接加载 html 文件更简单且更可取。我能找到的两个原因...

    • 当我编写/读取单元测试时,我希望所有信息都在我面前,而不是像我必须挖掘的资源文件那样成为“外部源”。个人喜好。
    • 这有点令人困惑,因为您可以将此方法用于其他事情,而不仅仅是从 html 文件中读取文本并对其进行分类。所以为了让它更通用,我只会在实际测试中使用原始文本。

    但是,我找不到您尝试做的事情真的很糟糕的原因,我认为这归结为个人喜好。

    【讨论】:

    • 谢谢,作为旁注,在我的测试中,我有一个设置阶段,取出相关段落并将它们中的每一个传递给分类函数(它接受字符串)。我认为我唯一不喜欢的是段落会变得很长并且覆盖整个屏幕。但这是一个特例。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-01-12
    • 2012-09-12
    • 2016-05-20
    • 2018-08-03
    • 2018-05-05
    相关资源
    最近更新 更多