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