Много тестов не бывает

[Mithgol]

Одобряю праведный пафос в заключении.

[arvitaly]

Спасибо за еще один пример в копилку для этого habrahabr.ru/post/190970/

[Krovosos]

Для интервала 29 января — 28 февраля ваша функция выдаст «0», правильно ли это? Между датами 30 дней, это больше чем весь февраль (28 дней).

ЗЫ Ну где же комментарий «На Delphi еще пишут?»? Скорее! У меня сейчас минусователь перегреется…

[headfire]

Да, в разделе «Несколько слов в оправдание фирмы Borland» я говорю, что существуют случаи, когда поведение функции однозначно определить сложно, но дальше я объясняю, почему считаю подход фирмы Borland неверным. Моя реализация тоже страдает неоднозначностью, но я про это тоже сказал:

Я написал верную, с точки зрения моих требований, функцию

Что касается «На Delphi еще пишут?", могу лишь ответить, что проект был написан на Delphi, когда она была популярна. В рамках проекта было нужно доработать систему.
По большому же счету считаю Delphi удачной системой. Хорошая была задумка. Жаль, что ее популярность снизилась. С уважением отношусь к людям, которые делают OpenSource аналоги Delphi, в том числе и под Linux.

P.S. Когда писал и отлаживал код, компиляция и прохождение тестов на моем стареньком ноутбуке занимало всего несколько секунд. Было немного непривычно.

[vsespb]

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

[headfire]

Я пользуюсь «Презумпцией невиновности». Считаю, что библиотеки работают правильно. Когда начинают валится мои тесты моего кода, разбираюсь в чем дело, и если виновата библиотечная функция, то добавляю тест (как Вы правильно заметили для отслеживания этого бага в будущих версиях). Иногда, и довольно часто, в случае разборок оказывается, что библиотечная функция работает правильно, это у меня мозги не в ту сторону развернуты. В этом случае правлю мозги, но тест все равно добавляю (теперь уже для моих мозгов).

[VolCh]

И в этих точках функция должна возвращать не противоречащее житейской логике значение.

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

3. Срок, исчисляемый месяцами, истекает в соответствующее число последнего месяца срока.
<...>
Если окончание срока, исчисляемого месяцами, приходится на такой месяц, в котором нет соответствующего числа, то срок истекает в последний день этого месяца.

P.S.

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

Эх, явно вы плотно с минутами и часами не работали. Один (не)переход на зимнее/летнее время чего стоит. А часовые пояса… А ещё високосная секунда бывает…

[headfire]

Спасибо за комментарий. Закон как всегда расставляет все на свои места.
Про високосную секунду я знал. А про зимнее и летнее время просто не подумал.
Наверное, закон и здесь может подсказать какое-нибудь верное решение.
В частности, меня интересует вопрос, как должен выглядеть отчет о каком либо параметре, меняющемся каждый час
за сутки, когда переводится время? Сколько в нем должно быть записей (11, 12 или 13)
и чего в них должно быть написано в графе время?

[VolCh]

Самое просто, использовать астрономическое или иное «абсолютное» время. А если использовать местное в сутки перевода, то так и будет 23 или 25 отсчетов за календарные сутки. В первом случае «пропуск» часа, во втором — «повтор». В софте, формирующем такие отчеты, это просто учесть. Главное не забыть про это в парсере этих отчетов.

[headfire]

Ок. Спасибо. Возможно это пригодится мне в будущем.

[DSparrow]

Интересная статья. Когда приходилось работать с датами у меня тоже много вопросов возникала концептуального характера:)
Ирония в том, что по логике вещей функция DeviceTimeExactMonthsBetween скорее всего должна быть real.
И как вариант подсчета количества месяцев между интервалами с использованием дней:
StartMonths:=(y1-BASE_YEAR)*12+m1+d1/d1max; EndMonths:=(y2-BASE_YEAR)*12+m2+d2/d2max;,
где d1max и d2max количество дней в соответствующих месяцах.

[headfire]

Согласен. В некоторых случаях такая реализация тоже может пригодится.

[VolCh]

Разве не нужно из d1 и d2 вычитать единицу перед делением? По идее нужно и для y и m, но там они нейтрализуются, т. к. целые слагаемые, а вот d — числитель дроби с изменяющимся знаменателем и 31 января не должен быть равен 28 февраля, а вот 1 января и 1 февраля должны быть равны.

[headfire]

Да, наверное для первого числа в числителе должен быть 0 (количество целых дней прошедшее с начального момента месяца). Можно также продолжить этот ход мыслей. Раз уж функция Real нужно идти до конца (учитывать также и время). Тогда в числителе будет количество секунд (или более мелких единиц) прошедшее с начала месяца (01.XX.XXXX 00.00), а в знаменателе — длина соответствующего месяца в секундах (или более мелких единицах).

[DSparrow]

Да, Вы правы… не досмотрел. Также «За» с автором статьи, чтобы считать все, вплоть до миллисекунд — дополнительная точность лишней не бывает, особенно при работе с временем и деньгами:)