Классы тестирования - Когда проводить рефакторинг? - PullRequest
2 голосов
/ 09 сентября 2011

Я пишу серию автоматических тестов на C # с использованием NUnit и Selenium.

Редактировать: я тестирую весь сайт, для начала я написал три класса для трех типов участников, которые используют сайт, эти классы содержат методы, которые используют selenium для выполнения различных действий этими участниками.Затем эти классы создаются и их методы вызываются моими тестовыми классами с соответствующими входными данными.

Мой вопрос:

Имеет ли значение, насколько большим становится мой тестовый класс?(то есть тысячи тестов?)

Когда пришло время провести рефакторинг моих классов функциональности?(25 или 50 методов, 1000 строк кода и т. Д.)

Я пытался прочитать все, что могу, о разработке тестов, поэтому, если у вас есть хорошие ресурсы, я буду признателен за ссылки.

1 Ответ

6 голосов
/ 09 сентября 2011

Имеет ли значение, насколько большим становится мой тестовый класс? (то есть тысячи тестов?)

Да, это так. Тесты необходимо поддерживать в долгосрочной перспективе, а огромный класс тестов трудно понять и поддерживать.

Когда пора реорганизовать мои классы функциональности? (25 или 50 методов, 1000 строк кода и т. Д.)

Когда вы начинаете чувствовать, что неловко найти конкретный контрольный пример или просмотреть тесты, связанные с конкретным сценарием. Я не думаю, что здесь есть жесткое ограничение, так же как нет жесткого ограничения для размера производственных классов или количества методов. Лично я ставлю ограничения выше для тестового кода, чем для производственного кода, потому что тестовый код имеет тенденцию быть проще, поэтому порог, когда его становится трудно понять, выше. Но в целом, тестовый класс из 1000 строк с 50 методами тестирования начинает казаться мне слишком большим.

Мне только недавно пришлось работать с таким тестовым классом, и я закончил его разделением, так что теперь у меня есть несколько тестовых классов, каждый из которых тестирует один конкретный метод / вариант использования определенного класса *. Некоторые из старых тестов мне удалось преобразовать в параметризованные тесты, а все новые тесты написаны как параметризованные тесты. Я обнаружил, что параметризованные тесты значительно облегчают просмотр общей картины и позволяют сразу помнить все тестовые примеры. Я сделал это с помощью JUnit в Java-проекте, но я вижу, что NUnit 2.5 теперь также предлагает параметризованные тесты - вы должны это проверить.

* Вы можете справедливо спросить, не следует ли провести рефакторинг тестируемого класса, если нам нужно так много тестовых случаев, чтобы его охватить - да, в конце концов, так и должно быть. Это самый большой класс в нашем унаследованном приложении, в котором слишком много всего. Но сначала нам нужно иметь тестовые случаи :-) Между прочим, это может относиться и к вашему классу - если вам нужно так много тестовых случаев, чтобы покрыть его, возможно, что тестируемый класс просто пытается сделать слишком много, и вам лучше выделить некоторые его функциональные возможности в отдельный класс с собственными модульными тестами.

...