Имеет ли значение, насколько большим становится мой тестовый класс? (то есть тысячи тестов?)
Да, это так. Тесты необходимо поддерживать в долгосрочной перспективе, а огромный класс тестов трудно понять и поддерживать.
Когда пора реорганизовать мои классы функциональности? (25 или 50 методов, 1000 строк кода и т. Д.)
Когда вы начинаете чувствовать, что неловко найти конкретный контрольный пример или просмотреть тесты, связанные с конкретным сценарием. Я не думаю, что здесь есть жесткое ограничение, так же как нет жесткого ограничения для размера производственных классов или количества методов. Лично я ставлю ограничения выше для тестового кода, чем для производственного кода, потому что тестовый код имеет тенденцию быть проще, поэтому порог, когда его становится трудно понять, выше. Но в целом, тестовый класс из 1000 строк с 50 методами тестирования начинает казаться мне слишком большим.
Мне только недавно пришлось работать с таким тестовым классом, и я закончил его разделением, так что теперь у меня есть несколько тестовых классов, каждый из которых тестирует один конкретный метод / вариант использования определенного класса *. Некоторые из старых тестов мне удалось преобразовать в параметризованные тесты, а все новые тесты написаны как параметризованные тесты. Я обнаружил, что параметризованные тесты значительно облегчают просмотр общей картины и позволяют сразу помнить все тестовые примеры. Я сделал это с помощью JUnit в Java-проекте, но я вижу, что NUnit 2.5 теперь также предлагает параметризованные тесты - вы должны это проверить.
* Вы можете справедливо спросить, не следует ли провести рефакторинг тестируемого класса, если нам нужно так много тестовых случаев, чтобы его охватить - да, в конце концов, так и должно быть. Это самый большой класс в нашем унаследованном приложении, в котором слишком много всего. Но сначала нам нужно иметь тестовые случаи :-) Между прочим, это может относиться и к вашему классу - если вам нужно так много тестовых случаев, чтобы покрыть его, возможно, что тестируемый класс просто пытается сделать слишком много, и вам лучше выделить некоторые его функциональные возможности в отдельный класс с собственными модульными тестами.