Comments 8
генерация тестовых данных — такой же неотъемлемый обязательный атрибут структуры данных, как и валидация с приведением из коробки
Интересно, задачи какого уровня вы решаете? Тестирование данных в веб-формах, для последующей обработки? Чтобы пользователь случайно либо намерено не осуществил какую-нибудь sql-инъекцию?
Я разработал и внедрил собственную учетную систему на производственном предприятии, которая проработала там двадцать лет и еще столько бы, если бы наша фирма не была бы поглощена более крупной, в которой своя, собственная, система учета, основанная на веб-технологиях, от которой, впрочем, они отказываются, в этом году, в пользу «восьмерки». Естественно, они забрали у меня мою работу. Но речь не об этом, а о необходимости «генерации тестовых данных».
Программа моя достаточно легкая и удобная для предприятий среднего уровня с количеством сотрудников порядка тысячи.
Когда я собирался ее опубликовать, то, естественно, возник вопрос о генерации данных, ну, не показывать же реальные данные, особенно, сотрудников. И даже немного поработал в этом направлении.
Как оказалось, задача эта действительно сложная. Хорошие данные, похожие на реальные, сделать трудно, хотя можно. Другое дело, что заточить прогу под нужды конкретного предприятия проще, чем сделать ее более-менее универсальной. Да и время не стоит на месте, то, что было востребовано двадцать лет назад, сейчас вряд ли кто будет использовать, хотя цена проекту – копейки. Не рискнут, без поддержки и гарантий со стороны ее автора. Лучше заплатят миллионы за внедрение современных аналогов. Поэтому, решил не заморачиваться этим проектом и заняться чем-то другим.
Это длинное вступление понадобилось только для одного вопроса. А так ли необходима генерация данных, по крайней мере, для десктопных программ? Думаю, что нет, мой опыт это доказывает. Для веба – может быть, и то, не очевидно. Ну, если вы утверждаете, что надо, тогда спорить не будем, как говориться, «из погреба виднее»… :)
Интересно, задачи какого уровня вы решаете?
Я пишу библиотеки общего назначения. Кто и как будет ее использовать — не моя забота. Моя забота — предоставить инструмент пользователю библиотеки, гарантирующий, что в систему не просочатся неконсистентные данные. И что неверный ввод не приведет к неожиданным последствиям.
Например, мы получаем поток каких-то данных. Ну, пусть прогноз погоды. Источник иногда чудит и присылает мусор. Как проверить, что мы корректно себя ведем при получении этого мусора? — Ну вот как-то так.
Генерируются не «похожие на правильные» данные, а ровно наоборот: любые.
Ну вот философский вопрос: как частным тестом можно подтвердить / доказать общее поведение?
Ну потыкать в граничные случаи, где ошибки происходят наиболее часто и всё.
Ну регресс может показать что на каких-то частных случаях, которые раньше работали они работают и теперь.
Тесты как трусы: прикрывают, но не защищают.
В тексте два раза встречается ссылка на property-based testing, которое как решает задачу доказательства (не на 100%, но близко к тому) общего поведения.
Ни в одной компании где я работал не писали тесты. Так что насчёт "принято" я бы поспорил.
Тесты как граждане первого сорта