Информация об изменениях

Сообщение Re[10]: Совсем отстой? от 10.11.2016 16:40

Изменено 10.11.2016 16:41 ·

Здравствуйте, Sinix, Вы писали:

S>·>Тесты должны проверять _все_ реальные сценарии использования. Как минимум те, до которых додумался программист (а раз он додумался до ассерта, то значит и до теста мог додуматься).

S>Я ещё раз повторюсь — все сценарии реально проверить на мелких проектах. На средних (один человек чисто физически не может охватить всю codebase) это нереально в принципе.
S>Поэтому остаётся или "что не проверили — ну и фиг с ним", или "пишем проверку, которая сработает при первой же попытке нагадить" и ждём теста / кода, который попытается.
S>Вся разница, что без ассертов попытка поломать код пройдёт незамеченной.
S>Кого-то это устраивает, кого-то нет.
Да нет жеж. Пиши, проверяй, ломай, но без ассертов. Заменяй ассерты чем-то другим. Используй другие инструменты.

S>·>А почему "строка в .csv содержит неэкранированный разделитель" нельзя проверить авто-тестом? Почему ассерт написали, а тест — нет?

S>·>Поменял культуру — програл test suite — посмотрел что упало.
S>Потому что нет никакого смысла воспроизводить все мыслимые и немыслимые ситуации для каждого _отдельного_ кусочка кода. Комбинаторный взрыв получается.
S>Как вы себе представляете тесты, которые должны проверяют корректность работы софта хотя бы в половине из случаев из вот этого списка?
Если и не тесты, то логгер, например, может помочь решить эти проблемы.

S>Комбинацией из ассертов + интеграционными тестами такие вещи ловятся на раз-два. Кто ленится — получает вот
Автор: DreamMaker
Дата: 28.08.16
это
Автор: Pavel_Agurov
Дата: 12.01.15
в подарок.

В проде он ничего не получит, получит unspecified behaviour, т.к. по определению в проде ассерты отключаются. А в дебаге он получит что-то лишь в том случае, если _догадается_ написать ассерт. А раз догадался написать ассерт — почему не написал тест?
Re[10]: Совсем отстой?
Здравствуйте, Sinix, Вы писали:

S>·>Тесты должны проверять _все_ реальные сценарии использования. Как минимум те, до которых додумался программист (а раз он додумался до ассерта, то значит и до теста мог додуматься).

S>Я ещё раз повторюсь — все сценарии реально проверить на мелких проектах. На средних (один человек чисто физически не может охватить всю codebase) это нереально в принципе.
S>Поэтому остаётся или "что не проверили — ну и фиг с ним", или "пишем проверку, которая сработает при первой же попытке нагадить" и ждём теста / кода, который попытается.
S>Вся разница, что без ассертов попытка поломать код пройдёт незамеченной.
S>Кого-то это устраивает, кого-то нет.
Да нет жеж. Пиши, проверяй, ломай, но без ассертов. Заменяй ассерты чем-то другим. Почему ты считаешь их незаменимыми? Используй другие инструменты.

S>·>А почему "строка в .csv содержит неэкранированный разделитель" нельзя проверить авто-тестом? Почему ассерт написали, а тест — нет?

S>·>Поменял культуру — програл test suite — посмотрел что упало.
S>Потому что нет никакого смысла воспроизводить все мыслимые и немыслимые ситуации для каждого _отдельного_ кусочка кода. Комбинаторный взрыв получается.
S>Как вы себе представляете тесты, которые должны проверяют корректность работы софта хотя бы в половине из случаев из вот этого списка?
Если и не тесты, то логгер, например, может помочь решить эти проблемы.

S>Комбинацией из ассертов + интеграционными тестами такие вещи ловятся на раз-два. Кто ленится — получает вот
Автор: DreamMaker
Дата: 28.08.16
это
Автор: Pavel_Agurov
Дата: 12.01.15
в подарок.

В проде он ничего не получит, получит unspecified behaviour, т.к. по определению в проде ассерты отключаются. А в дебаге он получит что-то лишь в том случае, если _догадается_ написать ассерт. А раз догадался написать ассерт — почему не написал тест?