Почему и как эффективно протестировать бета-версии R для обычного пользователя? - PullRequest
13 голосов
/ 29 ноября 2010

Этот вопрос основан на замечании Дункана Мердока в списке рассылки r-devel в ответ на сообщение об ошибке в Sweave:

Это исправлено в R-патчах. (Было бы были исправлены в 2.12.0, если больше люди проверяли бета-версии ...).

Честно говоря, я держался в стороне от бета-версии разработки по ряду причин, и это причины, которые я слышу от большего количества людей:

  1. Я немного в ужасе как-то вызывают конфликты с моим текущее распределение R Как мне это нужно для работы, необходимость регулярно ремонтировать это будет потеря время, которое я не могу объяснить своему боссу
  2. Я бы не знал, как проверить эффективно. Я считаю, что каждый тест я мог придумать уже управляется командой разработчиков.
  3. Мне все еще трудно понять, когда что-то ошибка, и когда (чаще всего) это мое вбрасывание глупости.

Но, как я понял, это было бы ценным вкладом в сообщество R, и я готов также внести свой вклад в тестирование, если смогу каким-то образом вписать его в свою работу. Я думал о том, чтобы держать бета-версию на стороне и проходить свои сценарии, а также проходить проверку. Сохранение построенных объектов позволяет быстро и просто all.equal() увидеть, если что-то не так.

Кто-нибудь еще / лучшие идеи о том, как я мог бы помочь в тестировании с минимальными усилиями и максимальной эффективностью?

Я также хотел бы рассказать об этом немного больше в нашем отделе. Помимо «Пришло время вернуть сообществу», есть еще какие-либо веские причины, почему тестирование бета-версий стоит усилий? Как я могу противостоять приведенным выше аргументам?

Edit:

Как отметил в комментариях Дирк Эддельбюттель, часть сделки заключается в предотвращении переменных пути в Windows. У меня есть некоторые идеи по этому поводу, но рекомендации по организации вашего компьютера для тестирования версий R-devel также высоко ценятся.

Ответы [ 2 ]

5 голосов
/ 29 ноября 2010

Боюсь, вы неправильно поняли. Поначалу это может быть не просто и не очевидно, поэтому может быть полезно:

  • "исправлено" не является "бета". Исправлено то, что R 2.12.1 будет.

  • Конфликта нет. Это падает для 2.12.0.

  • Это отдельная загрузка, а ночная сборка доступна здесь .

  • Это не r-devel, а r-patched.

  • Наша обязанность как пользователей также тестировать предварительные версии. Так что, если что, идеальным словом вы бы установили R-patched - а также R-devel!

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

3 голосов
/ 29 ноября 2010

Я бы понятия не имел, как эффективно проводить тестирование.Я считаю, что каждый тест, который я мог придумать, уже был выполнен командой разработчиков.

Мне все еще трудно понять, когда что-то является ошибкой, и когда (чаще всего) это моя собственная глупость.в.

Проблема в том, что разработчики не будут (или не только) использовать программное обеспечение.Он будет использоваться людьми, которые могут вообще не обладать знаниями в области программирования (я говорю вообще, это справедливо как для R, так и для любого другого программного обеспечения).

Если помощь или интерфейс илиобщий способ сборки программного обеспечения не дает вам достаточной информации о том, как что-то сделать, ну, возможно, это не ошибка, но это то, что можно улучшить (и указать разработчикам).

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

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

...