Маленький разработческий трюк
Стартуем новый проект. Внезапно придумал хотя и очевидный, но забавный трюк.
Раньше всегда было как? Берем структуру объектов и их отношений в нашей системе, и переносим ее в РСУБД. Со всеми удобствами в виде редактора диаграммы БД в SQL Server Management Studio, как правило. Потом по этим объектам БД делаем руками или генерируем объекты, с которыми работаем потом в коде. Естественно, скрипт создания базы загоняется в систему контроля версий, и каждый прогон тестов начинается с создания базы с нуля и наполнения ее тестовыми данными. Потом база бэкапится, и перед каждым тестом восстанавливается из бэкапа, чтобы избежать неожиданных наведенных ошибок в тестах.
А тут объектов не так много, и вместо того, чтобы сперва задать структуру данных РСУБД я почему-то решил, что а ну его нафиг. Пусть все объекты хранятся в in-memory storage. Дешево и сердито. При запуске тестов все равно надо заполнять базу тестовыми данными, почему бы не делать это и при каждом запуске стендового приложения? Заодно при прогоне тестов исключаются и накладные расходы на резервное копирование и построение БД с нуля, и на заполнения ее тестовыми данными. Плюс, это деликатно способствует тому, чтобы тестовый/стендовый код, который наполняет пустую базу тестовыми данными, всегда находился в рабочем сосотоянии. Ну и при изменении структуры данных не нужно сперва редактировать структуру БД в одном редакторе, а потом править или перегенерировать бизнес-объекты, живующие в коде, в другом редакторе. Достаточно подправить сами классы бизнес-объектов, и, возможно, устройство in-memory storage.
Раньше всегда было как? Берем структуру объектов и их отношений в нашей системе, и переносим ее в РСУБД. Со всеми удобствами в виде редактора диаграммы БД в SQL Server Management Studio, как правило. Потом по этим объектам БД делаем руками или генерируем объекты, с которыми работаем потом в коде. Естественно, скрипт создания базы загоняется в систему контроля версий, и каждый прогон тестов начинается с создания базы с нуля и наполнения ее тестовыми данными. Потом база бэкапится, и перед каждым тестом восстанавливается из бэкапа, чтобы избежать неожиданных наведенных ошибок в тестах.
А тут объектов не так много, и вместо того, чтобы сперва задать структуру данных РСУБД я почему-то решил, что а ну его нафиг. Пусть все объекты хранятся в in-memory storage. Дешево и сердито. При запуске тестов все равно надо заполнять базу тестовыми данными, почему бы не делать это и при каждом запуске стендового приложения? Заодно при прогоне тестов исключаются и накладные расходы на резервное копирование и построение БД с нуля, и на заполнения ее тестовыми данными. Плюс, это деликатно способствует тому, чтобы тестовый/стендовый код, который наполняет пустую базу тестовыми данными, всегда находился в рабочем сосотоянии. Ну и при изменении структуры данных не нужно сперва редактировать структуру БД в одном редакторе, а потом править или перегенерировать бизнес-объекты, живующие в коде, в другом редакторе. Достаточно подправить сами классы бизнес-объектов, и, возможно, устройство in-memory storage.