Когда это в порядке для изменения “завершенных” модульных тестов?
Черт, я никогда не замечал эту ошибку в JDOM 2.
Вы получите те же результаты, что и любой персонаж, не принадлежащий к BMP. Вы можете попробовать смайлики мании последних лет и увидеть, что вы получите те же результаты.
Это происходит из-за того, что стратегия escape автоматически устанавливается для кодировок UTF, независимо от кодировки. То, что он делает, довольно неправильно.
Это будет исправлено, если вы замените стратегию на стратегию, которая ничем не отличается от зарезервированных символов XML:
format.setEscapeStrategy((c) -> false);
6 ответов
Для «правильного» TDD вы сначала меняете тест, затем меняете код.
Так что на самом деле вы никогда не нарушали тесты, только сломанный код. Вы всегда должны стремиться быть в положении, когда тесты являются окончательным выражением правильной функциональности и, как таковые, априори правильны.
Тесты - это спецификация поведения программы. Вы меняете их, когда вам нужно изменить спецификации, потому что они являются спецификациями. Некоторые из них приходят мне на ум ...
- Когда требования к коду изменились и тест не соответствует новому поведению, вы должны обновить их.
- Когда некоторые требования устаревают, тесты, которые определяют это поведение должен быть удален.
Основное качество, которое должен иметь тестовый код, это удобочитаемость. Поэтому вы должны регулярно менять тесты из-за ...
- Если тест труден для чтения и не раскрывает всех намерений программиста, его следует реорганизовать для улучшения его читабельности.
Тогда есть также случаи, когда тесты не работают, например, хрупкие тесты для параллельного кода, которые в основном проходят, но время от времени дают сбой, хотя код правильный. В таких случаях тесты должны быть исправлены, чтобы быть более повторяемыми (для этого может потребоваться изменить код, чтобы его было легче тестировать - лучше всего избегать / ограничивать параллелизм с помощью подходящих шаблонов проектирования).
Смысл каждого отдельного модульного теста не в том, что он никогда не ломается, а в том, что он продолжает работать, пока работает функция, которую он тестирует. Таким образом, случайное изменение тестируемой функции приведет к провалу теста, о котором узнаете вы, а не ваш конечный пользователь.
Если функция была изменена намеренно, вы должны ожидать, что некоторые тесты сломаются. Если вы этого не сделаете, значит, вы недостаточно охватили эту функцию в наборе тестов.
Когда вы вносите изменение, которое нарушает тесты:
1) Сначала выясните, не работает ли тест сейчас или ваше изменение нарушило тест, которого не должно было быть.
2). Если первое, исправьте тест. В противном случае внесите изменения.
Когда требования изменятся. Независимо от того, измените ли вы свой код, а затем посмотрите, какие тесты сломались по какой причине (как предложил Митч), или измените свои тесты, а затем измените свой код (как упоминал Visage), тесты будут меняться только в том случае, если функциональность предполагалось, что сделает что-то другое.
Каждый раз, когда вам нужно.
- Тесты должны быть изменены, если они стали неточными или больше не соответствуют спецификациям.
- Тесты следует удалить, если они стали неактуальными.
Дело в том, что ваши тесты должны давать точное представление о том, как ваше программное обеспечение должно работать. Конечно, это будет немного сложно поддерживать, и, действительно, это одно из самых больших отклонений от TDD, уступающее только программированию «сначала тесты».