Является ли это хорошим способом тестирования кода Perl?

Question

Я пишу модуль, который имеет некоторые функции, связанные с текстовыми файлами. Я новичок в тестировании, поэтому решил пойти с Test::More. Вот как выглядит мой тестовый файл:

use mymod; 
use 5.10.0; 
use strict; 
use warnings; 
use Test::More 'no_plan'; 

my $file_name = "test.file"; 

sub set_up { 
    my $self = shift; 
    open(my $handle,">",$file_name) or die "could not create file test.file $!\n"; 
    # generate a sample text file here 
    close($handle); 
} 

sub tear_down { 
    my $self = shift; 
    unlink($file_name) or die "could not delete $file_name $!\n"; 
} 

set_up(); 

open(my $handle,$file_name) || die "could not open $file_name $!\n"; 

my @lines = mymod->perform($handle); 

is_deeply(\@lines,["expected line","another expected line"]); 

close($handle); 

tear_down(); 

Это хороший способ проведения тестов? Хорошо ли иметь дело с созданием входного файла образца в моем тесте?

Кстати, я начал писать это как тест Test::Unit, а затем переключился на Test::More. Вот почему функции set_up и tear_down есть.

Answer 1

Использование опции Test :: More 'no_plan' делает тестирование менее надежным: вы не можете действительно знать, пропустили ли вы по какой-либо причине тесты. Лучше всего планировать предопределенное количество тестов, или если это невозможно, вы можете использовать функцию done_testing (но это потребовало последней версии Test :: More).

ETA: Я не вижу использования функции open-close-open-close-unlink, которую вы делаете. Я думаю, вы можете лучше открыть временный файл, заполнить его и использовать его для своих тестов.

Answer 2

Кроме того, использование no_plan, который уже быть прокомментированы:

Что касается генерации файла для чтения во время модульного тестирования, это можно считать приемлемым, хотя в общем случае предпочтительно, чтобы avoid touching the files in the unit tests (или любой другой «медленный» ресурс), потому что это замедляет тесты.

Это может стать проблемой, если устройство тестирует или записывает файл, и если количество тестов слишком велико. В самом деле, единичные тесты должны быть ненавязчивыми и работать быстро.

Если время выполнения ваших модульных тестов начинает становиться проблемой, вы можете либо извлечь тесты, которые обращаются к файловой системе, и добавить их в тестовый пакет интеграции, в котором вы будете работать менее часто, или вы можете изменить свой код на отделите чтение файла и обработку его содержимого. Таким образом, вы можете протестировать обработку содержимого независимо от чтения файла и иметь данные, хранящиеся в массиве строк в вашем модульном тестовом коде.

Этот тип кода имеет тенденцию быть более пригодным для повторного использования, поскольку то, что вы читаете в файле сегодня, может происходить из другого источника (например, сети, БД) вчера.

Answer 3

Вы можете «открыть» строку как дескриптор файла, так что вы все равно можете подать свой метод дескриптором файла, но не должны создавать физический файл. Таким образом, вы могли бы поставить содержание теста в строке (в идеале массив строк, по одному для каждой выборки данных для проверки против) и не должны создавать временные файлы:

my @testdata = (
    "test data 1", 
    "test data 2", 
    # ... 
); 

foreach my $data (@testdata) 
{ 
    open my $datahandle, "<", \$data or die "Cannot open handle to string: $!"; 
    my @lines = mymod->perform($datahandle); 
    # ... 
}