Андрей Светлов
Сам по себе _test_html_fresh не имеет смысла (по крайней мере в моем случае) - это по сути staticmethod, так как не может вызывать методы экземпляра (потенциально небезопасные).

Я бы сказал проще. Он не имеет смысла, так как не имеет смысл тестировать <=. К этой идее я и подвожу :)
Так же бессмысленно проверять стандартные библиотечные функции.

Андрей Светлов
Попробуйте написать аналог для refresh_html.

А тут следующая идея. Какая обязанность у класса Post? В основном - обращение к библиотечным средствам. Высокоуровневых действий мало. Вот они:

Если руководствоваться чем-то типа “Single responsibility principle”, то можно выделить эти куски из класса. При том, даже в обычные функции, а не в методы. И тестировать эти функции. Остальное в классе - набор обращений к API, его не имеет смысла проверять юнит-тестами. Тут нужен другой инструмент.

Примечание: не понял, зачем во втором отрывке нужен title. Кроме того, мне интересно, что будет, если в параметр rst_file конструктора Post передать пустую строку.

Андрей Светлов
Подмена FileSystem всяко лучше и удобней.

Проблема в том, что сам класс Post по сути является двойником этого FileSystem. А имеет ли смысл тестировать классы FileSystem и Impl?

Ок. Ещё раз спасибо за терпение.

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

Вообще-то у “живого” класса Post хватает разных интересных функций.
Например, он сериализует часть своих атрибутов в yaml.
Эти атрибуты тоже непростые: их изменение помечает пост как “несинхронизированный”, заодно извещая конфигурацию.
И так далее.

title - заголовок поста. Может указываться как из command line так и браться из rst, если он там есть.

При тестировании я стараюсь исходить из того, что весь код должен быть покрыт тестами - если явно не оговорено обратное. Например, в юниттестировании GUI я обычно не делаю тестов для View/Widget/Form - их создать практически невозможно. Или это крайне неудобно при очень малой выгоде.

Post - не двойник FileSystem. У FileSystem хватает и других клиентов.
Если бы они были двойниками - достаточно было бы сделать _Impl у Post.
Тестировать FileSystem нужно. Например, там есть функция "найти относительный по отношению к проекту путь и проверить, лежит ли файл внутри проекта.
* project
- .blogspot.yaml
- article1.rst
* multithreading
- article1.rst
- article2.rst
В качестве относительных путей фигурируют multithreading/article1.rst, при этом есть взаимное преобразование относительных и абсолютных.
Я хочу получить возможность свободно перемещать проект по файловой системе, не переконфигурируя его при этом.
Тесты для этого нужны хотя бы потому, что я уже пару раз исправлял ошибки.

Тестировать _Impl смысла нет, что правда то правда.

О списке литературы. Идея неплохая. К сожалению, я читал лишь бумажного Кента Бека весьма давно, и много-много статей в тернете по этому поводу.
Если порекомендуете хорошие ссылки - я их добавлю.

Андрей Светлов
title - заголовок поста. Может указываться как из command line так и браться из rst, если он там есть.

Я намекал на то, что можно сразу присвоить self.title = ‘ ’.join(md.Meta)

Андрей Светлов
Post - не двойник FileSystem. У FileSystem хватает и других клиентов.

Ну нет, так нет.

Андрей Светлов
О списке литературы. Идея неплохая. К сожалению, я читал лишь бумажного Кента Бека весьма давно, и много-много статей в тернете по этому поводу.
Если порекомендуете хорошие ссылки - я их добавлю.

Я как раз о бумажной литературе и говорил.

1. Майкл Физерс, Эффективная работа с унаследованным кодом:
http://www.williamspublishing.com/Books/978-5-8459-1530-6.html

Думаю, тут к статье близка глава 15. Как раз рассмотрен подход с обёрткой и альтернатива. Книга хороша тем, что решает задачи более близкие к практике, чем известная книга Кента Бека. Правда, примеров на Python я там не заметил :)

2.Стив Макконнелл, Совершенный код:
http://www.ozon.ru/context/detail/id/3159814/
Тут глава 22 (22.2, 22.3). Для полной картины можно с 20-й главы читать. Эта книга хороша своим критическим подходом к тестированию. Есть некоторая статистика по эффективности юниттестирования.

Книги Кента Бека приводить не буду - и так понятно.

Извиняюсь за длительное молчание.

Я намекал на то, что можно сразу присвоить self.title = ‘ ’.join(md.Meta)

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

Знаете, за прошедшую неделю код, на котором я основывал статью, несколько поменялся.
Возможно, я бы построил свои примеры немного иначе - особенно после того, как Денис Откидач столь убедительно опроверг тезисы для первого решения.
Честно сказать, я попросту забыл (а быстрым поиском не нашел), что os.utime отлично позволяет изменять время изменения файла.

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

Добавил список литературы по вашей рекомендации.

Огромное спасибо за обсуждение. Для меня оно было очень полезным.