О креативном подходе к тестированию
Здравствуйте, b_manvelyan, Вы писали:
_> а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
Это не является стандартной техникой, это часть креативного подхода к тестированию. В данном случае речь идет о regression tests (тесты, доказывающие что вы ничего в старой системе не изменили), которые делаются достаточно халявным образом - старый код не вырезается, а ставится под флаг компиляции, таким образом, что в тестовом режиме работает одновременно старый и новый код, сравнивается их вывод, и любое несовпадение пишется в лог. Так мы, например, делали в CQG, проверяя корректность построения временных рядов новой версии. Удобно - вы пользуетесь системой, а она сама пишет в лог о вероятных ошибках.
Также в тестовом режиме можно проверять инварианты и также писать об их невыполнении в лог. Мы так тоже делали. Удобно - стоит сервер месяцами, обрабатывает себе тихонько котировки, а ты раз в неделю ищешь баги в файле errors.log
Плюсы тестовых режимов - вам не нужно делать окружения для тестов - роль окружения играет сама ваша система. И делает она это великолепно.
Вообще - тестовые режимы делать не обязательно. Regression test можно организовать и исключительно сверкой логов. Скажем, вы логгируете промежуточные результаты в набор файлов с системы до модификаций. Получаете что-то вроде трейса выполнения программы. После чего - берете diff с логами новой версии, и объясняете различия (не все типы различий будут ошибками в новой версии).
Другой подход к regression-тестированию - сверка состояний. Вы пишете в лог состояние системы в контрольных точках, для старой и новой систем, и так же берете diff. Там мы, например, отлаживали модель процессора MIPS - сравнивали состояние памяти после выполнения тестовой программы, в качестве эталона брали состояние памяти обычной настольной машины.
Короче, если как следует подумать о тестировании, можно съэкономить массу времени при разаботке. Вот еще пример - как отлаживать конечные автоматы. Пишем в лог одну запись на переключение состояния. Лог имеет форму таблицы с разделителями-табуляциями. После чего даем системе поработать, подцепляем лог-файл как таблицу MS Access, и одним SQL-запросом строим из нее матрицу смежности конечного автомата, для сравнения со спецификацией. Удобно? А то . Я так сам делал.
Основной плюс всех перечисленных методов - вам эти unit-tests достаются вам как бы бесплатно, вы их автоматически из общесистемных получаете.
_> а где можно узнать побольше о таких "тестовых режимах"? правильно ли я понимаю, что при включенном таком режиме одновременно может работать и старых код (до рефакторинга) некой подсистемы и новый код (полученный после рефакторинга). Можно об этом рассказать подробнее?
Это не является стандартной техникой, это часть креативного подхода к тестированию. В данном случае речь идет о regression tests (тесты, доказывающие что вы ничего в старой системе не изменили), которые делаются достаточно халявным образом - старый код не вырезается, а ставится под флаг компиляции, таким образом, что в тестовом режиме работает одновременно старый и новый код, сравнивается их вывод, и любое несовпадение пишется в лог. Так мы, например, делали в CQG, проверяя корректность построения временных рядов новой версии. Удобно - вы пользуетесь системой, а она сама пишет в лог о вероятных ошибках.
Также в тестовом режиме можно проверять инварианты и также писать об их невыполнении в лог. Мы так тоже делали. Удобно - стоит сервер месяцами, обрабатывает себе тихонько котировки, а ты раз в неделю ищешь баги в файле errors.log
Плюсы тестовых режимов - вам не нужно делать окружения для тестов - роль окружения играет сама ваша система. И делает она это великолепно.
Вообще - тестовые режимы делать не обязательно. Regression test можно организовать и исключительно сверкой логов. Скажем, вы логгируете промежуточные результаты в набор файлов с системы до модификаций. Получаете что-то вроде трейса выполнения программы. После чего - берете diff с логами новой версии, и объясняете различия (не все типы различий будут ошибками в новой версии).
Другой подход к regression-тестированию - сверка состояний. Вы пишете в лог состояние системы в контрольных точках, для старой и новой систем, и так же берете diff. Там мы, например, отлаживали модель процессора MIPS - сравнивали состояние памяти после выполнения тестовой программы, в качестве эталона брали состояние памяти обычной настольной машины.
Короче, если как следует подумать о тестировании, можно съэкономить массу времени при разаботке. Вот еще пример - как отлаживать конечные автоматы. Пишем в лог одну запись на переключение состояния. Лог имеет форму таблицы с разделителями-табуляциями. После чего даем системе поработать, подцепляем лог-файл как таблицу MS Access, и одним SQL-запросом строим из нее матрицу смежности конечного автомата, для сравнения со спецификацией. Удобно? А то . Я так сам делал.
Основной плюс всех перечисленных методов - вам эти unit-tests достаются вам как бы бесплатно, вы их автоматически из общесистемных получаете.