По какому принципу разбивать наборы модульных тестов?
Прошу прояснить чем нужно руководствоваться и каким вопросом задаваться, чтобы принять решение о том что нужно писать новый набор модульных тестов вместо того чтобы дописывать тесты к одному из существующих.
Под набором тестов имею ввиду англоязычное "Suite". Ту ситуацию когда мы привязываем тесты к некоторому именованному пространству. Для этого мы можем применять макрос BOOST_AUTO_TEST_SUITE в случае использования Boost.Test или первый параметр TEST/TEST_F в случае использования GoogleTest и т.д. и т.п..
У меня возникла следующая ситуация и мне непонятно, а стоит ли создавать новый тестовый набор или нет?
Я пишу код по работе с форматом исполняемых файлов PE32\PE32+ и этот код покрываю юнит-тестами. Одним из важных алгоритмов является преобразование Rva в FileOffset, очень часто именуемая как RvaToRaw() или ImgRvaToOffset(), есть и др. названия. Этот алгоритм должен работать как на 32-битных, так и на 64-битных образах, а также имеются несколько нюансов связанных со значениями SectionAllignment, FileAlignment в заголовке.
Возникает вопрос: Как организовывать наборы модульных тестов для проверки этого алгоритма?
Пока вижу такие варианты:
1. Создать набор с именем RvaToRawTest и в нем различные тесты, к примеру: when32image, when64image, whenSectionAndFileAlignmentEquals и т.д. и т.п.
2. Можно создать несколько наборов RvaToRawImage32Test, RvaToRawImage64Test, RvaToRawSectionAndFileAlignmentImage32Test, RvaToRawSectionAndFileAlignmentImage64Test
3. Можно создавать тестовый набор исходя из того что для тестов нужен образ с определенной ситуацией, к примеру SectionHeadersIncomplete32Test и SectionHeadersIncomplete64Test
альтернатив достаточно много, но остановиться на чем-то одном надо. Поделитесь опытом, пожалуйста! ;)
Я обычно руководствуюсь абсолютно теми же соображениями, что при создании классов. Т.е. связность и зацепление.
Т.е. только если не выйдет раздутие на много тысяч строк, я бы использовал первый вариант. В противном случае мы привносим красивость архитектуры в жертву читаемости, вот и все.
