1) Тестировать команды отдельно что они работают со всеми правильными состояниями (из правильных состояний возникают правильные состояния, на неправильные состояния ругаются)
Небольшой интеграционный тест на то, что части работают вместе.
2) В тесте подсунуть фейк объекта файловой системы выбрасывающий тот же эксепшн, что и при выдергивании флешки
3) Я не вижу никаких сложностей в разработке вебсайта в стиле TDD
В-общем, непонятно, при чем тут TDD — TDD не требует покрытия всех классов эквивалентности, оно требует писать код только после красного теста и писать самый простой код который проходит тесты.
>>>А это не суть важно. Как-то взаимодействуют и все. Сколько вариантов порядка вызова трех функций есть?
Тестирование вообще невозможно потому, что порядок вызова функций зависит от входных данных. Так?
При чем тут асинхронность вообще?
TDD и абсолютная 100% уверенность в корректности кода это разные вещи.
>>>У меня требование — работать в случае получения от клиента любого мусора. Если получен мусор нужно ругнуться ошибкой и закрыть соединение.
>>>Опять же я не могу предугадать, что будет делать клиент, а следовательно нормально покрыть тестами эту часть.
>>>Корректное поведение предсказуемо и нормально покрывается тестами. Отлов некорректного поведения может быть только >>>частичный, все некорректное поведение другой стороны — счетное множество комбинаций (пусть время квантуется).
Некорректное поведение тоже предсказуемо и нормально покрывается тестами. Например если на вход функции подается строка и корректными являются строки длинной от 1 — до 10 символов не надо перебирать все варианты достаточно послать null, пустую строку и строку длинной 11 символов.
Причем соверщенно пофиг какие именно эти 11 символов. Надо тестировать классы эквивалентности а не все варианты входных значений.
Тут есть две проблемы:
1. Вы не знаете контракт клиента полностью — это решается его исследованием
Я не вижу в чем проблема протестировать write_cb на неприятие мусора — вызвать его с мусором, и протестировать что результат совпадает с ожидаемым.
2. Проблема взаимодействия асинхронного кода. Тут хотелось подробнее — в данном коде взаимодействие не показано вообще.
Давайте выберем конкретное требование и посмотрим какие сложности возникают.
>>>Я могу протестировать данный код в случае, если вторая сторона диалога исполняет свои обязанности корректно
Дык TDD это про тестирование известных требований, а не про выдумывание новых. Я бы насытил код ассертами на предусловия, постусловия и инварианты и прочей диагностикой, чтобы схватить ошибку как можно раньше.
1. В синхронном коде я не вижу проблем с тестированием обработки исключения от выткнутой флешки
2. Асинхронный код я не знаю, но давайте разберем какой-нибудь конкретный пример мне самому интересно:
— дайте пример кода
— дайте пример требования, которое нужно протестировать (я бы предпочел C# )
3. Так как по запросу «async TDD» что-то находится, хотелось бы от вас тезисно разобрать хотя бы одну из известных вам рекомендаций по тестированию асинхронного.
1. Если есть новая информация, то это скорее добавление мертвого кода, чем рефакторинг. Я бы разбил на два этапа: преобразование в структуру с единственным полем и добавление новых полей с использующим их кодом.
2. Почему вытаскивание флешки не тестируется? С асинхронным кодом не знаком но поиск что-то находит. Заметьте, шор делает оговорку про использование фреймворков не предназначенных для тестирования, во-вторых, можно побольше логики выжать, например из View во ViewModel, чтобы кода для тестирования view почти не было
Можно ли как-нибудь обосновать этот тезис с примерной калькуляцией расходов на производство книги (насколько переменные и постоянные затраты связанные с выходом тиража бумажной отличаются от таких для электронной)
>>>Тут что-то добавили, или тут переместили. В результате тесты упали (как и должны), и надо обновлять все тесты?
Это зависит от того, что есть System under test, следуя Пути Тестовой Пирамиды у вас не должно быть много тестов тестирующих страницу целиком.
>>>Рефакторинг — это очень сложно, и в момент рефакторинга может поменяться логика.
В момент рефакторинга не должна меняться логика. Это достигается использованием автоматических инструментов (типа Resharper) и тестами. Потребность в конкретном рефакторинге часто возникает при имплементации конкретной фичи. Для этого сначала делают рефакторинг, потом проверяют его результат, потом имплементируют фичу на рефакторенном коде. Или как в TDD (red->green->refactor) пишут новую фичу копипастом, потом объединяют получившиеся куски. С точки зрения управления продуктом рефакторинг в этом случае промежуточный этап при выполнении фичи.
«How can I use TDD when developing a user interface?
TDD is particularly difficult with user interfaces because most UI frameworks weren't designed with testability in mind. Many people compromise by writing a very thin, untested translation layer that only forwards UI calls to a presentation layer. They keep all of their UI logic in the presentation layer and use TDD on that layer as normal.
There are some tools that allow you to test a UI directly, perhaps by making HTTP calls (for web-based software), or by pressing buttons or simulating window events (for client-based software). These are essentially integration tests and they suffer similar speed and maintainability challenges as other integration tests. Despite the challenges, these tools can be helpful.
»
>>>Ситуация 1. Программисты забыли освободить неиспользование ресурсы — это бага!!! Проблема не может быть решена покупкой памяти. Ну сегодня, мы купим еще 100500 гб памяти, а через неделю опять не хватит. Дальше может быть еще хуже
этом случае можно периодически перезапускать процесс, чтобы нейтрализовать результат лика
Небольшой интеграционный тест на то, что части работают вместе.
2) В тесте подсунуть фейк объекта файловой системы выбрасывающий тот же эксепшн, что и при выдергивании флешки
3) Я не вижу никаких сложностей в разработке вебсайта в стиле TDD
Тестирование вообще невозможно потому, что порядок вызова функций зависит от входных данных. Так?
При чем тут асинхронность вообще?
TDD и абсолютная 100% уверенность в корректности кода это разные вещи.
>>>У меня требование — работать в случае получения от клиента любого мусора. Если получен мусор нужно ругнуться ошибкой и закрыть соединение.
>>>Опять же я не могу предугадать, что будет делать клиент, а следовательно нормально покрыть тестами эту часть.
>>>Корректное поведение предсказуемо и нормально покрывается тестами. Отлов некорректного поведения может быть только >>>частичный, все некорректное поведение другой стороны — счетное множество комбинаций (пусть время квантуется).
Некорректное поведение тоже предсказуемо и нормально покрывается тестами. Например если на вход функции подается строка и корректными являются строки длинной от 1 — до 10 символов не надо перебирать все варианты достаточно послать null, пустую строку и строку длинной 11 символов.
Причем соверщенно пофиг какие именно эти 11 символов. Надо тестировать классы эквивалентности а не все варианты входных значений.
en.wikipedia.org/wiki/Equivalence_partitioning
1. Вы не знаете контракт клиента полностью — это решается его исследованием
Я не вижу в чем проблема протестировать write_cb на неприятие мусора — вызвать его с мусором, и протестировать что результат совпадает с ожидаемым.
2. Проблема взаимодействия асинхронного кода. Тут хотелось подробнее — в данном коде взаимодействие не показано вообще.
Давайте выберем конкретное требование и посмотрим какие сложности возникают.
>>>Я могу протестировать данный код в случае, если вторая сторона диалога исполняет свои обязанности корректно
Дык TDD это про тестирование известных требований, а не про выдумывание новых. Я бы насытил код ассертами на предусловия, постусловия и инварианты и прочей диагностикой, чтобы схватить ошибку как можно раньше.
2. Асинхронный код я не знаю, но давайте разберем какой-нибудь конкретный пример мне самому интересно:
— дайте пример кода
— дайте пример требования, которое нужно протестировать (я бы предпочел C# )
3. Так как по запросу «async TDD» что-то находится, хотелось бы от вас тезисно разобрать хотя бы одну из известных вам рекомендаций по тестированию асинхронного.
Давайте разберем конкретный пример кода и требования которое вы хотите протестировать?
PS. Про детерминированность тестов: en.wikipedia.org/wiki/Fuzz_testing
techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html
2. Почему вытаскивание флешки не тестируется? С асинхронным кодом не знаком но поиск что-то находит. Заметьте, шор делает оговорку про использование фреймворков не предназначенных для тестирования, во-вторых, можно побольше логики выжать, например из View во ViewModel, чтобы кода для тестирования view почти не было
Это зависит от того, что есть System under test, следуя Пути Тестовой Пирамиды у вас не должно быть много тестов тестирующих страницу целиком.
>>>Рефакторинг — это очень сложно, и в момент рефакторинга может поменяться логика.
В момент рефакторинга не должна меняться логика. Это достигается использованием автоматических инструментов (типа Resharper) и тестами. Потребность в конкретном рефакторинге часто возникает при имплементации конкретной фичи. Для этого сначала делают рефакторинг, потом проверяют его результат, потом имплементируют фичу на рефакторенном коде. Или как в TDD (red->green->refactor) пишут новую фичу копипастом, потом объединяют получившиеся куски. С точки зрения управления продуктом рефакторинг в этом случае промежуточный этап при выполнении фичи.
Цытата:
www.jamesshore.com/Agile-Book/test_driven_development.html
«How can I use TDD when developing a user interface?
TDD is particularly difficult with user interfaces because most UI frameworks weren't designed with testability in mind. Many people compromise by writing a very thin, untested translation layer that only forwards UI calls to a presentation layer. They keep all of their UI logic in the presentation layer and use TDD on that layer as normal.
There are some tools that allow you to test a UI directly, perhaps by making HTTP calls (for web-based software), or by pressing buttons or simulating window events (for client-based software). These are essentially integration tests and they suffer similar speed and maintainability challenges as other integration tests. Despite the challenges, these tools can be helpful.
»
Тесты, в частности и нужны, чтобы с архитектурой было все так.
У вас новые фичи никогда не требуют изменения общих кусков кода? Как вы этого добиваетесь без рефакторинга и дублирования кода?
этом случае можно периодически перезапускать процесс, чтобы нейтрализовать результат лика
«Если бы существовал бесплатный аналог бензина, то и правда было бы странно не запрещать автомобили без паруса, согласитесь?»
Машина есть принуждение к покупке бензина.
«полностью корректно работающий» — это что значит — без единого бага?