В-общем, непонятно, при чем тут 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 гб памяти, а через неделю опять не хватит. Дальше может быть еще хуже
этом случае можно периодически перезапускать процесс, чтобы нейтрализовать результат лика
1. habrahabr.ru/post/231325/?reply_to=7820487#comment_7817957
2. Это потребует также заменить методы на нестатические и добавить фасадный статик метод как сказали ниже. Вы книжку про рефакторинг читали? Видели сколько там усилий предпринимается, чтобы ничего не сломать?
Тестирование вообще невозможно потому, что порядок вызова функций зависит от входных данных. Так?
При чем тут асинхронность вообще?
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.
»
Тесты, в частности и нужны, чтобы с архитектурой было все так.
У вас новые фичи никогда не требуют изменения общих кусков кода? Как вы этого добиваетесь без рефакторинга и дублирования кода?
этом случае можно периодически перезапускать процесс, чтобы нейтрализовать результат лика
«Если бы существовал бесплатный аналог бензина, то и правда было бы странно не запрещать автомобили без паруса, согласитесь?»
Машина есть принуждение к покупке бензина.
«полностью корректно работающий» — это что значит — без единого бага?
2. Это потребует также заменить методы на нестатические и добавить фасадный статик метод как сказали ниже. Вы книжку про рефакторинг читали? Видели сколько там усилий предпринимается, чтобы ничего не сломать?