|
12.03.2011, 23:47 | #1 |
Участник
|
Цитата:
Сообщение от kornix
потом объявляется разработчик, который не знал про то что вы завязаны на это поле (поле нестандартное, стандарт не так часто ломают), и изменяет код заполнения этого поля. Его задача тестируется - переносится на рабочую, а ваш алгоритм превращается в реальную ошибку.
Виноват в такой ситуации не ваш код, он был действительно работающим, тут вы правы. Но бывают и такие "преобразования Фурье" |
|
13.03.2011, 11:59 | #2 |
MCP
|
Цитата:
Сообщение от gl00mie
По-моему, если якобы протестированный код при изменении входных данных перестает работать (и не просекает, что данные некорректны), то такой код просто недостаточно корректно реализован с точки зрения контрактного программирования. Более скользкие случаи - это расширение списка значений enum'ов, которые на самом деле могут стать подставой (как, к примеру, RContractPartnerType, где всю жизнь были лишь клиенты и поставщики, а потом вдруг нарисовался персонал), но строго говоря даже при работе с каким-нить ModuleCustVend надо в switch предусматривать default, где выбрасывать исключение - мол, не знаю, что сделать с новым значением.
Цитата:
а его незащищенность от подобных изменений, а именно: отсутствие регрессионнных тестов, проверяющих функциональность данного кода.
|
|
13.03.2011, 16:32 | #3 |
Участник
|
Цитата:
К тому же тесты сейчас делают редко
Цитата:
причина проста: код может прекрасно пройти все тесты, но при этом оказаться не пригоден к задаче..
Цитата:
Так что главный тест - это работа в реальных условиях, а следовательно описанные выше баги неизбежны...
Цитата:
2 kuntashov: Вы делаете регрессионное тестирование каждой модификации?
__________________
С уважением, Александр Кунташов |
|