Только начинаю разбираться с модульным тестированием в Visual Studio. Интересно было бы узнать, кто какие схемы именования использует и как вообще организует хранилище с тестами.

Здравствуйте, Alex0808, Вы писали:

A>Только начинаю разбираться с модульным тестированием в Visual Studio. Интересно было бы узнать, кто какие схемы именования использует и как вообще организует хранилище с тестами.
Почитайте книжку Шаблоны тестирования xUnit Месароша.

Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, Alex0808, Вы писали:

A>>Только начинаю разбираться с модульным тестированием в Visual Studio. Интересно было бы узнать, кто какие схемы именования использует и как вообще организует хранилище с тестами.
LVV>Почитайте книжку Шаблоны тестирования xUnit Месароша.

LaptevVV, благодарю вас!

Здравствуйте, Alex0808, Вы писали:

A>Только начинаю разбираться с модульным тестированием в Visual Studio. Интересно было бы узнать, кто какие схемы именования использует и как вообще организует хранилище с тестами.

Лично я придерживаюсь простых правил:
— Тестируем не класс, а функциональность. Каждый тестовый класс соответствует конкретному действию в конкретном контексте. Например, операции сложения. Каждый тестовый метод соответствует проверке конкретного результата. Например, результат есть сумма операндов.
— Отсюда названия, которые должны реально отражать функциональность системы, а в идеале -- легко трансформируемы в документацию.

Плохо:
класс: RegistrationServiceTester
метод: ServiceWorksFine

Хорошо:
класс: User_Submits_Registration_Form_With_Valid_Data
метод: Registration_Record_Appears_In_DB
метод: Registration_Record_Contains_Same_Data
метод: Email_Confirmation_Is_Sent

Далее создаем отдельный тектовый класс для обработки ситуации с повторяющимся Email, и т.д.

Идея сопоставить каждому классу тестовый класс, а каждому методу -- тестовый метод, работает только в проектах в стиле "сделаем это по-быстрому" и убивает на корню принцип TDD (хотя, конечно, никто не запрещает заниматься модульным тестированием без TDD, но пользы от этого немного.)

Здравствуйте, ulu, Вы писали:

ulu>Здравствуйте, Alex0808, Вы писали:

A>>Только начинаю разбираться с модульным тестированием в Visual Studio. Интересно было бы узнать, кто какие схемы именования использует и как вообще организует хранилище с тестами.

ulu>Лично я придерживаюсь простых правил:
ulu>- Тестируем не класс, а функциональность. Каждый тестовый класс соответствует конкретному действию в конкретном контексте. Например, операции сложения. Каждый тестовый метод соответствует проверке конкретного результата. Например, результат есть сумма операндов.
ulu>- Отсюда названия, которые должны реально отражать функциональность системы, а в идеале -- легко трансформируемы в документацию.

ulu>Плохо:
ulu>класс: RegistrationServiceTester
ulu>метод: ServiceWorksFine

ulu>Хорошо:
ulu>класс: User_Submits_Registration_Form_With_Valid_Data
ulu>метод: Registration_Record_Appears_In_DB
ulu>метод: Registration_Record_Contains_Same_Data
ulu>метод: Email_Confirmation_Is_Sent

ulu>Далее создаем отдельный тектовый класс для обработки ситуации с повторяющимся Email, и т.д.

ulu>Идея сопоставить каждому классу тестовый класс, а каждому методу -- тестовый метод, работает только в проектах в стиле "сделаем это по-быстрому" и убивает на корню принцип TDD (хотя, конечно, никто не запрещает заниматься модульным тестированием без TDD, но пользы от этого немного.)

Очень вам благодарен во-первых потому, что использовал как раз приведенную в качестве плохого примера схему А во-вторых электронной версии книги "Шаблоны тестирования xUnit" увы не нашел.

Здравствуйте, Alex0808, Вы писали:
A> А во-вторых электронной версии книги "Шаблоны тестирования xUnit" увы не нашел.

http://xunitpatterns.com/