Мне кажется, тесты должны быть модульными, то есть для всего, что не входит в модуль, должны быть заглушки/mock-объекты.
12 мая 2012 г., 23:52 пользователь Akzhan Abdulin <[email protected]>написал: > Первый вариант идеален в некоторых случаях (как минимум, чтобы у нативного > кода не было дополнительных зависимостей). > Во всех прочих случаях приходится использовать второй вариант. > > 12 мая 2012 г., 23:22 пользователь Vladimir Timofeev > <[email protected]>написал: > > 12 мая 2012 г., 21:58 пользователь Ivan Petrov >> <[email protected]> написал: >> > вот когда просто на cpan модуль загружаем или когда XS-модуль без >> > зависимостей загружаем, то в итоге множество хостов его тестируют и >> > если что-то не так, то присылают письма. >> > >> > а вот если XS-модуль зависит от какой-то библиотеки, скажем libabc.so, >> > то как правильно оформить модуль? не прикладывать же исходники libabc? >> >> Есть много мнений )) >> >> Вот эти модули поставляются вместе с исходниками сторонних библиотек: >> * EV >> * Alien::SVN >> >> А вот эти, к примеру, нет: >> * XML::LibXML >> * Net::SSLeay >> >> => Правильного решения не существует. >> >> Я вижу такие особенности этих двух вариантов. >> Если поставлять исходный код библиотеки вместе с модулем, то: >> + Можно модифицировать код, вставлять свои патчи, к примеру. >> + Установка может быть проще для конечного пользователя. >> + Можно рассчитывать свой модуль на конкретную версию библиотеки, не >> надо поддерживать изменения в API. >> + Можно линковать стороннюю библиотеку статически (что повышает скорость) >> - Дистрибутив раздувается (иногда очень сильно) по размеру. >> - Приходится самому писать (и, главное, поддерживать) систему сборки >> сторонней библиотеки у конечного пользователя со всеми вытекающими >> win,vms, зоопарком компиляторов и т.п. >> - Сторонняя библиотека тоже может зависеть от других библиотек, а еще >> от окружения (см. п. выше) >> - Гораздо больше сил приходится тратить на поддержку, т.к. каждая >> новая версия библиотеки влечет новую версию модуля на CPAN >> - Лицензия сторонней библиотеки может затруднить или сделать >> невозможным её включение в дистрибутив модуля >> >> Если модуль ожидает, что нужная библиотека уже есть в системе >> пользователя, то: >> + Не паримся мелкими версиями (пока API совместимо, у нас все будет >> работать) >> + Система сборки становится сильно проще (все проблемы по установке >> библиотеки лежат на пользователе) >> + Остальные минусы из первого варианта исчезают ;-) >> - Все же приходится писать систему для обнаружения библиотеки у >> пользователя: >> - Найти, если нет, выдать приемлемое сообщение об ошибке (и для >> пользователя и еще CPAN тестерами озаботиться...) >> - Если нашли, угадать ключи компиляции/линковки, которые нам надо >> добавить для сборки... >> - Проверить версию, поддерживаемая ли... >> >> Как то так. Лично я склоняюсь ко второму варианту, он попроще для >> разработчика. >> Конечно будет совсем здорово, если у Perl появится стандартная система >> описать внешние зависимости у CPAN-модуля, но пока её нет, к >> сожалению. >> >> > -- >> > Moscow.pm mailing list >> > [email protected] | http://moscow.pm.org >> >> >> >> -- >> Vladimir Timofeev <[email protected]> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org >> > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > > -- С уважением, Александр Личный блог: http://eax.me/ Мой форум: http://it-talk.org/ Мой Twitter: http://twitter.com/afiskon
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
