Привет.
В посте Тесты, которые тестируют тесты я описал свой взгляд на верификацию программ через дублирование их логики в виде отдельной модели и последующее сравнение с ней. В качестве частного случая выступили юнит-тесты.
В этот раз, опираясь на изложенные идеи, я попробую сформулировать общий подход к оценке уровня верифицированности ПО.
Сначала я хотел назвать этот текст «Зачем нужен бизнес-план», но к чему себя ограничивать? План — он и в Африке план, не важно для чего. Тот, что для бизнеса, называется бизнес-планом. Тот, что для эвакуации, называется, как ни странно, планом эвакуации. И так далее.
Но идея текста таки пришла из области, где актуальны бизнес-планы. Часто стал встречаться с высказываниями о том, что «бизнес-план, конечно, нужен, но вот конкретно в нашем случае он пользу не принесёт потому, что»:
Сам я тоже страдал этими тараканами, но так получилось, что периодически разного рода планы составлять всё-таки приходилось. И хочу вам сказать — планы делать полезно и нужно.
Но сначала…
Известно, что у open source софта часто есть большие проблемы с интерфейсом. Принято считать, что это из-за того, что замкнутые эгоцентричные программисты пилят его для себя, а им интерфейс не нужен.
Чушь:
На самом деле проблема в самой модели разработки, ориентированной на совместную работу сообщества равноправных людей.
Демократические группы умеют многие вещи делать хорошо, но одна у них удаётся откровенно плохо — это управление концептуальной целостностью.
Толпа народу просто не может оперировать этим понятием. В большинстве случаев, без лидера-диктатора любое начинание такой группы превращается в хаос. И компромиссы не помогают, так как приводят только к появлению нежизнеспособных химер.
Исключения есть, но ровно в том количестве, чтобы подтверждать это правило.
Одной из практик тестирования является написание тестов по уже найденным ошибкам, чтобы исключить их в будущем. Но что делать, если ошибка не специфична для конкретной логической сущности, а может встретиться в любом месте?
Писать для каждого модуля одинаковые тесты — не самая вдохновляющая идея, тем более, о них ещё помнить надо. В некоторых случаях тест можно написать не для проверки поведения программы, а для проверки непосредственно её кода. Этакий семантический pep-8, если хотите.
В коде «Сказки» уже давно прописалось несколько таких тестов, собранных в файле test_code.py
. О них и расскажу, для иллюстрации идеи.
На этой неделе наконец включил донат в своей игрушке.
Расскажу о том, как и кудой я этот донат делал. А также как вообще можно организовать приём денег у нас в стране максимально простым способом. Под максимально простым способом я понимаю получение денег на беларуское юр. лицо в родной валюте, без заморочек с открытием фирм в левых странах, приёма иностранной валюты и подобных вещей.