您将如何测试过滤复杂对象的东西

发布于 2024-07-27 15:45:16 字数 1421 浏览 4 评论 0原文

我有一个包含 7 个相关字段的持久对象。

这些字段可以保存此处列出的值的数量:

Field    # of Possible Values
1        5
2        20
3        2
4        2
5        19
6        2
7        8

这可能包含 121600 个唯一对象。

被测试的代码是许多过滤器,它们根据字段的值抓取一定数量的这些对象,然后将它们放入一个容器中以供另一个系统使用。 垃圾箱存放很简单,经过测试并且工作正常......只是过滤不起作用。 似乎有许多边缘情况没有被覆盖,并且许多对象在根本不应该被选择时被放置在垃圾箱中,反之亦然。

总而言之,有 9 个过滤器按责任链运行,每个过滤器将对象放入垃圾箱中,直到垃圾箱满了,此时链退出。 链中的最后一个过滤器只是一个“过滤器”,它向管理员发送一封电子邮件,指出对象正在运行不足(即,如果链到达此过滤器,则垃圾箱未满,需要某些东西被关注)。

所以我的问题是:如何测试这些过滤器? 我可以使用一系列 for 语句创建每种独特类型的对象:

public void FixtureSetup()
{
    for(each possible value for field 1)
    {
        for(each possible value for field 2)
        {
            // ... continue with 5 more for statements

            // Create Object with each value
        }
    }
}

但是尝试手动找出应该从结果集合(甚至是过滤对象的集合)中正确过滤哪些对象将非常困难(如果可能的话,当我第一次编写过滤器时,我会很容易做到这一点)。

我知道这些要求是有问题的,因为他们说了这样的话:

filter 1 gets
    - field 1: values 1/2/3
    - field 2: values 2/3/4
    - etc.

但结果显示了如此多的边缘情况,每次我更改它以包含该特定情况时,都会出现其他问题(而且我没有回归测试来确保但事实并非如此)并且很难找出特定问题发生在链条中的哪个位置。

编辑> 我试图单独测试过滤器,但假设如下:

过滤器 1 抓取 121600 个可能对象中的 500 个(根据过滤器的标准)。 我发现,比如说 100 个(完全猜测)那些被抓取的物体,不应该被抓取——并且出于不同的原因。 为了知道这一点,我必须与其他系统的用户一起检查每个过滤器,以了解每个过滤器的结果集是否正确。 与此相反的情况也萦绕在我的脑海中……所有应该被抓住但没有被抓住的物体又如何呢?

我开始认为这可能是需求收集的问题,而不是测试的问题。

I have a persistent object with 7 pertinent fields.

The fields can hold the number of values listed here:

Field    # of Possible Values
1        5
2        20
3        2
4        2
5        19
6        2
7        8

Which is a potential for 121600 unique objects.

The code under test is a number of filters that grab a certain number of these objects based on the values of their fields, and then puts them in a bin for use by another system. The bin depositing is trivial, tested, and works properly... it's just that the filtering isn't working. There seems to be many edge cases that aren't being covered and many objects are being placed in a bin when they shouldn't be selected at all or vice versa.

All in all, there are 9 filters which operate in a chain of responsibility, each filter putting objects in a bin until the bin is full, at which point the chain exits. The last filter in the chain is simply a 'filter' that sends an e-mail to an admin noting that the objects are running low (ie, if the chain reached this filter, then the bin isn't full, and something needs to be looked at).

So my problem is this: How do I test these filters? I could create one of each unique type of object using a series of for statements:

public void FixtureSetup()
{
    for(each possible value for field 1)
    {
        for(each possible value for field 2)
        {
            // ... continue with 5 more for statements

            // Create Object with each value
        }
    }
}

But trying to manually figure out what objects should be properly filtered from the resulting collection (even the collection of filtered objects) would be terribly difficult (and if possible, I would have easily done it when I first wrote the filters).

I'm aware that the requirements are at fault because they say something like:

filter 1 gets
    - field 1: values 1/2/3
    - field 2: values 2/3/4
    - etc.

but the results are showing so many edge cases, that each time I change it to include that particular case, something else breaks (and I have no regression tests to ensure that it doesn't) and it's difficult to find out where in the chain the particular issue occurred.

edit> I am trying to test the filters separately, however assume the following:

filter 1 grabs 500 of the 121600 possible objects (according to the filter's criteria). I'm finding that, say 100 (complete guess) of those objects that are grabbed, shouldn't be - and for varying reasons. In order to know, I'd have to go through each one with the user(s) of the other system to know if the result set of each filter is correct. The opposite to that also lingers in my mind... what about all of the object that should have been grabbed, but weren't.

I'm starting to think that this might be a problem in requirements gathering, and not testing.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

妖妓 2024-08-03 15:45:16

听起来您没有明确的规格。 如果你没有明确的规范,那么你怎么可能知道代码是否按照规范工作?

退后一步。 首先编写一个单句规范

FrobFilter 组件获取一系列 Frobs,并将每个 FlobBin 放入正确的 FrobBin 中,直到一个 bin 已满。

好的,现在您已经完成了得到了一个规格。 它还不是一个可测试或可实现的规范。 为什么不? 有两个原因。

原因一:Frob序列用完之前FrobBin没有填满的后果尚未明确。

原因二:未指定“正确”。

现在写一个一句话规范来解决每个问题。

如果序列在某个 bin 已满之前结束,则会通知管理员。

Frob 的正确 bin(例如 Blargh 是 Gnusto)始终是 FrotzBin。

好的,现在您已经有了还有两个问题。 如何通知管理员? 如果Frob's Blargh不是Gnusto,会发生什么?

只要继续分解它,一次一句话,直到你得到一个完整而准确的规范。 然后您会发现您的规范、实现的程序以及测试用例都非常相似。 这是一个很棒的情况。

It sounds like you do not have a clear spec. If you don't have a clear spec then how can you possibly know whether the code works according to spec?

Take a step back. Start by writing a one sentence spec:

The FrobFilter component takes a sequence of Frobs and places each one in the correct FrobBin until one bin is full.

OK, now you've got a specification. It's not a testable or implementable specification yet. Why not? Two reasons.

Reason One: the consequence of no FrobBin filling up before the Frob sequence runs out has not been specified.

Reason Two: "correct" is not specified.

Now write a one-sentence spec that addresses each concern.

If the sequence ends before some bin is full then the administrator is notified.

The correct bin for a Frob such that Blargh is Gnusto is always the FrotzBin.

OK, now you have two more problems. How is the administrator notified? And what happens if the Frob's Blargh is not a Gnusto?

Just keep on breaking it down, one sentence at a time, until you have a complete and accurate spec. Then you'll find that your spec, the program which implements, and the test cases all look remarkably like each other. And that is an awesome situation to be in.

送你一个梦 2024-08-03 15:45:16

听起来您应该分别测试每个过滤器,并在每个要链接的过滤器“下方”放置一个模拟过滤器。

希望每个过滤器都很简单,并且可以简单地进行测试。

当一切都连接好后,我会对整个事情进行一些集成测试。

It sounds like you should be testing each of these filters separately, with a mock filter "underneath" each one to be chained to.

Hopefully each of the filters is simple, and can be tested simply.

I'd then have a few integration tests for the whole thing when it's all wired up.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文