а всякие тесты помогли не делать это таким мучительным?

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

скажем, мы пошли брутальным путем

на самом деле, я плохо представляю, как это тестировать. наверное, ниндзя умеют, но на то они и ниндзя
вот, допустим, в пандах ввели новое обозначение для пропущенных, независимо от типа серии
как это тестировать в коде, который собирает данные и делает их них агрегаты для дашбордов - не очень понятно
аналогично - если вдруг они когда-нибудь решат не исключать NA-значения в значениях группирующей переменной при группировке, явно сломается очень многое. но как это хорошо оттестировать - непонятно.

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

наверное, можно тестировать простым каким-то примером. Вот первые сто строк, на таком-то этапе должен появится такой-то объект, на следующем шаге другой... Занудно, но в результате сразу будет видно, на каком шаге все ломается.

Но да, надо смолоду. Постфактум уже вставлять проверки всюду без особой надобности не будешь...

это ваше защитное программирование... везде натыкать проверок и логов можно, я даже как-то пробовал писать такой код, когда работал с грязными данными
но времени уходит уйма, имхо, проще идти проактивно, "упало - поднял". а для этого дешевле обновляться регулярно.

одна из самых неочевидных штук, кстати, которая мне попадалась - если читать и обрабатывать файлы в lapply-цикле, а потом их склеивать через rbindlist, то можно потерять что-нибудь.
например, у меня в результате обработки так получилось, что таблица оказалась пустой, неправильно пофильтровался. rbindlist сожрал без особых проблем, просто пропустил пустую таблицу и все. в результате пришлось делать проверку, что количество элементов в списке, подаваемом в rbindlist равно количеству элементов, по которым итерировались (в моем случае вектор названий файлов)

@artemklevtsov имхо, кандидат на pr в репу. не хотишь? :)))

Какую репу?

data.table

Если ты про перевод, то скоро будет, правда нам ещё вычитать всё надо.

я про проверку rbindlist

В идеале код надо паковать в пакеты и тестировать нормальными юнит-тестами на сэмплах данных со всеми аномалиями.

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

так то в идеале
у нас десятка три разных борды минимум

нарисую минут через 20 наверн

Написание тестов - это априори трудоёмкий и неблагодарный труд, который в перспективе должен окупиться пойманными ошибками.

ну вот нам дешевле поднимать упавшее, кажется

Тесты позволяют сразу понимать где и почему падает, а в реальности иногда надо целые расследования проводить, чтобы выяснить причину.

Опять всё сводится к дилемме сделать хорошо/правильно или быстро/в срок.

ну вот да было бы хорошо проверку делать

Не все знают как писать тесты, что тестировать и как это внедрять в проекты. И вариантов это сделать множество, как в R, так и в Python.

вот, смотри

> tmp <- list(
+   data.table(v1 = 1, v2 = 'a'),
+   data.table(),
+   data.table(v1 = 3, v2 = 'c')
+ )
> rbindlist(tmp)
   v1 v2
1:  1  a
2:  3  c