Мне нужно построить модульные тесты в среде с очень старой версией Test::More
(perl5.8 с $Test::More::VERSION being '0.80'
), которая предшествовала добавлению done_testing()
.Каков самый идиоматический способ эмуляции теста Perl :: More :: done_testing?
Обновление до более нового теста :: Больше не может быть и речи по практическим соображениям. И я стараюсь избегать использования no_tests
- это, как правило, плохая идея не ловить, когда ваш юнит-тест выходит преждевременно - скажем, из-за какой-то логики, которая не выполняется, когда вы этого ожидали.
Что является наиболее идиоматическим способом запуска настраиваемого количества тестов, не предполагая no_tests
или done_testing()
используются?
Детали:
Мои юнит-тесты обычно принимают форму:
use Test::More; my @test_set = ( [ "Test #1", $param1, $param2, ... ] ,[ "Test #1", $param1, $param2, ... ] # ,... ); foreach my $test (@test_set) { run_test($test); } sub run_test { # $expected_tests += count_tests($test); ok(test1($test)) || diag("Test1 failed"); # ... }
Стандартный подход use Test::More tests => 23;
или BEGIN {plan tests => 23}
не работает так как, очевидно, выполняется перед тем @tests
известно ,
Мой текущий подход предполагает создание @tests
глобального и определения его в BEGIN {}
блоке следующим образом:
use Test::More; BEGIN { our @test_set =(); # Same set of tests as above my $expected_tests = 0; foreach my $test (@tests) { my $expected_tests += count_tests($test); } plan tests => $expected_tests; } our @test_set; # Must do!!! Since first "our" was in BEGIN's scope :( foreach my $test (@test_set) { run_test($test); } # Same sub run_test {} # Same
Я чувствую, что это может быть сделано более идиоматически, но не уверен, как улучшить. Главным среди запахов является дубликат our @test_test
деклараций - в BEGIN{}
и после него.
Другой подход заключается в эмулировать done_testing()
по телефону Test::More->builder->plan(tests=>$total_tests_calculated)
. Я не уверен, что это лучше идиоматично.
Каковы практические причины не модернизации Test :: More? – Schwern
Под «no_tests» я полагаю, вы имеете в виду «no_plan»? Он отлично работает, если ваш тест умирает преждевременно. Единственное условие, при котором проблема «no_plan» становится проблемой, заключается в том, что ваш тест выходит рано и обычно. Попробуй. – Schwern
@Schwern - это основной модуль. Получение программного обеспечения для его утверждения потребует больше времени и усилий (рецензии, презентации, убедительное управление, тестирование всей компании), чем я могу обосновать руководство, когда единственный компромисс - это более простые тесты устройства – DVK