我需要多少时间来测试 Moose 和 MooseX::FollowPBP 生成的方法?

发布于 2024-08-21 10:39:33 字数 1548 浏览 8 评论 0原文

我想开始严格进行测试驱动开发。但是,我想知道应该对 Moose 和 MooseX::FollowPBP 生成的方法进行多少测试。例如,我有以下课程:

package Neu::Series;
use Moose;
use MooseX::FollowPBP;

use File::Find::Wanted;

has 'file_regex' => (
    isa=>'RegexpRef',
    is=>'rw',
    default => sub{
                 qr{
                   [A-Z]       #Uppercase letter
                   [a-zA-Z]*   #any letter, any number of times
                   [-]         #dash
                   (           #open capturing parenthesis
                   [0-9]
                   [0-9]
                   [0-9]
                   [0-9]
                   [a-zA-Z]?   #any letter, optional
                   )           #close capturing parenthesis
               }xms;
           },
);


has 'top_dir' => (
    isa=>'Str',
    is=>'rw',
);


has 'access' =>(
    isa=>'Neu::Access',
    is=>'ro',
    required=>1,

);

1;

我当前的测试脚本是:

use strict;
use warnings;
use Test::More tests => 8;
use Neu::Access;

BEGIN{ use_ok('Neu::Series'); }

can_ok( 'Neu::Series', 'new');
can_ok( 'Neu::Series', 'set_file_regex');
can_ok( 'Neu::Series', 'get_file_regex');
can_ok( 'Neu::Series', 'set_top_dir');
can_ok( 'Neu::Series', 'get_top_dir');
can_ok( 'Neu::Series', 'get_access');

my $access = Neu::Access->new(dsn => 'test');
my $series_worker = Neu::Series->new(access => $access);

isa_ok($series_worker, 'Neu::Series');

这是足够的测试还是太多的测试? (也就是说,除了明显缺少的正则表达式测试之外)。

我以为我在某个地方看到过有关此问题的网页或其他帖子,但今天我找不到它。

I want to start strictly doing Test-Driven-Development. However, I was wondering how much I should test methods generated by Moose and MooseX::FollowPBP. For example, I have the following class:

package Neu::Series;
use Moose;
use MooseX::FollowPBP;

use File::Find::Wanted;

has 'file_regex' => (
    isa=>'RegexpRef',
    is=>'rw',
    default => sub{
                 qr{
                   [A-Z]       #Uppercase letter
                   [a-zA-Z]*   #any letter, any number of times
                   [-]         #dash
                   (           #open capturing parenthesis
                   [0-9]
                   [0-9]
                   [0-9]
                   [0-9]
                   [a-zA-Z]?   #any letter, optional
                   )           #close capturing parenthesis
               }xms;
           },
);


has 'top_dir' => (
    isa=>'Str',
    is=>'rw',
);


has 'access' =>(
    isa=>'Neu::Access',
    is=>'ro',
    required=>1,

);

1;

My current test script is:

use strict;
use warnings;
use Test::More tests => 8;
use Neu::Access;

BEGIN{ use_ok('Neu::Series'); }

can_ok( 'Neu::Series', 'new');
can_ok( 'Neu::Series', 'set_file_regex');
can_ok( 'Neu::Series', 'get_file_regex');
can_ok( 'Neu::Series', 'set_top_dir');
can_ok( 'Neu::Series', 'get_top_dir');
can_ok( 'Neu::Series', 'get_access');

my $access = Neu::Access->new(dsn => 'test');
my $series_worker = Neu::Series->new(access => $access);

isa_ok($series_worker, 'Neu::Series');

Is this enough or too-much testing? (That is, besides the obviously missing tests for the regex).

I thought I saw a web page or another post about this somewhere, but I haven't been able to find it today.

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

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

发布评论

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

评论(4

近箐 2024-08-28 10:39:33

测试访问器是否正确生成确实没有意义。如果它们不是,您很快就会发现,因为您编写的任何实际测试都会失败。

Moose 本身测试访问器是否正确生成,使用 Moose 的类是否获得构造函数,等等。使用依赖项的要点之一是让您可以专注于编写和测试应用程序,而不是帮助程序代码。

我确实同意 daotoad,它可能值得测试您自己编写的约束和强制

There's really no point in testing that the accessors were generated correctly. If they're not, you'll find out very quickly, because any real tests you write will fail.

Moose itself tests that accessors are generated correctly, that Moose-using classes get a constructor, and so on. One of the points of using dependencies is so that you can focus on writing and testing your application, not helper code.

I do agree with daotoad, it's probably worth testing constraints and coercions that you write yourself.

べ繥欢鉨o。 2024-08-28 10:39:33

检查所有访问器是否正确生成是很好的...但是您可以在稍高的级别上测试其他一些东西,例如为什么不测试属性是否正确生成?

use Test::Deep;
my @attrs = Neu::Series->meta->get_all_attributes;
cmp_deeply( [ map { $_->name } @attrs ], superbagof(qw(file_regex top_dir access)));

Checking that all accessors were generated correctly is fine... however there are other things you could test at a slight higher level, e.g. why not test that the attributes were generated properly?

use Test::Deep;
my @attrs = Neu::Series->meta->get_all_attributes;
cmp_deeply( [ map { $_->name } @attrs ], superbagof(qw(file_regex top_dir access)));
给我一枪 2024-08-28 10:39:33

我会专注于测试我的规格。我是否正确地告诉了 Moose 我希望它做什么?

为此,我将从以下测试开始:

  • 验证读/写属性是否同时具有访问器和修改器。
  • 验证只读属性是否有访问器且没有修改器。
  • 测试任何类型约束和强制。验证是否只能设置可接受的值。如果属性 sIf 您希望将 VII 视为 Str 并强制转换为 Int 作为 7,请测试确实如此。

I'd focus on testing my specification. Did I tell Moose what I wanted it to do correctly?

To this end, I'd start with the following tests:

  • Verify that read/write attributes have both an accessor and a mutator.
  • Verify that read only attributes have an accessor and no mutator.
  • Test any type constraints and coercions. Verify that only acceptable values can be set. If an attribute sIf you expect VII to be seen as a Str and coerced into an Int as 7, test that it does.
两个我 2024-08-28 10:39:33

谢谢 Dave、daotoad、Ether、Elliot 和 brian。通过阅读您的答案、评论和博客,似乎有两个要点:

(1) 不需要进行测试来确保 Moose 执行其应该执行的操作。我想大家都同意这一点。

(2) 测试 Moose 生成的方法适用于建立、测试和维护您的接口。大多数人都同意这一点。

再次感谢大家的意见。

编辑:

这只是社区维基摘要。请阅读各个答案和评论。

Thank you Dave, daotoad, Ether, Elliot, and brian. From reading your answers, comments, and blogs, there seem to be two salient points:

(1) No testing is needed to make sure Moose does what it is supposed to do. I think everyone agrees on this point.

(2) Testing Moose-generated methods is appropriate for establishing, testing, and maintaining your interface. Most agree on this point.

Again, thanks to everyone for your input.

EDIT:

This is just a community-wiki summary. Please read the individual answers and comments.

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