Никто не сталкивался с такой ситуацией:
Написание тестов мешает потом изменять структуру кода.

Т.е. мы пишем unit тест который проверяет работу одного класса, тем самым фиксируя его интерфейс.
Если же мы хотим произвести рефакторинг, переместить какие либо методы, поменять структуру,

то существующие Unit тесты нужно будет менять.. это _сильно_ напрягает.

Может быть я что-то не правильно понимаю или делаю не так ?

P.S. Модераторам: Не нашел раздела ООП на нашем форуме, поэтому пишу в наш родной perl форум. Если есть более подходящий раздел - переместите.

Уважаемый sir_nuf_nuf,

Проблема в том, что Вы пишите обычные модульные тесты, а надо писать самомодифицирующиеся интеллектуальные модульные тесты, которые покрывают текущий и все будующие функционалы модуля  

Если при рефакторинге сильно напрягает модификация тестов, единственный выход - отказаться от них. Но тогда, возможно, начнут сильно напрягать ошибки, проявляющиеся в самый неподходящий момент   

Ого, а подробнее можно?

KSURi, мож юмор? (смайлик, как никак)

не, все серьезно.. пора писать модуль на CPAN   

А если все таки серьезно, как смотрите на такие идею как:

тестировать не каждый класс, а фасад к модулю.. так сказать public интерфейс =)
вообще это противоречит идеям Unit тестирования, зато очень ловко делать рефакторинг.
Фактически можно менять внутренности модуля как угодно, главное что бы снаружи все работало.
 

Это сообщение отредактировал(а) sir_nuf_nuf - 6.8.2008, 14:01

Ответ на этот вопрос является продолжением ответа на вопрос: "зачем Вы используете unit testing".

а что за модуль ради интереса qt/gkt/openql?

мне всегда казалось что ООП как и предназначено для "сокрытия реализации" - т.е. вы меняеете внутреннюю работу класса а его внешний интерфейс (или public методы) остаются неизменными....Если вы меняете и public интерфейс - тогда придется менять и все вызовы методов данного класса....По мне так это ошибка проектирования изначального класса и его public методов....

p.s. Если меняется только внутренняя страктура класса (а она в свою очередь тоже покрыта тестами), я бы рекомендовал тестировать только public методы данного класса, так как они по сути должны оставаться неизменными....

Для чего тебе нужны тесты: получить оценку работоспособности методов класса. Для этого необходимо получить оценку работоспособности каждого метода и сделать выводы по понравившемуся тебе правилу. Чтобы оценить работоспособность метода необходимо иметь информацию о способе вызова этого метода, наборы входных и выходных параметров, а так же взаимосвязь между входными и выходными параметрами. Эту информацию можно поместить в классе в унифицированном виде.

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

Это сообщение отредактировал(а) tishaishii - 13.8.2008, 15:20