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