Сообщение Re: Что и как следует покрывать юнит-тестами от 30.12.2015 19:56
Изменено 31.12.2015 21:17 Pauel
Здравствуйте, FrozenHeart, Вы писали:
FH>Скажите, пожалуйста, всегда ли вы пишете юнит-тесты? На каких языках вы программируете и какие библиотеки используете для их написания? Делаете 100% покрытие кода тестами или "забиваете" на юнит-тестирование определённых частей проекта?
Важно определиться с тем какую проблему ты решаешь. Тесты это не улучшайзер, это проверка качества. Если вспомнить, что качество это степень соответствования требованиям, то сразу вопрос — какие требования ?
Вот например ты пилишь компонент, который кидает эвент ready когда его состояние из loading стало complete. Вопрос- как ты к этому пришел ?
Например было так — "мы решили что здесь будет эвент". В этом случае никаких тестов писать нет смысла.
А если ты взял какую формальную модель, спроектировал на ее основе решение, то, внезапно, есть смысл проверить, обладает ли твое решение требуемыми свойствами формальной модели
Естественно, проверяешь не все, а только ту часть, на которую полагается вызывающий код. А именно
1 поведение
2 вычисления
3 реакция — сигналы об изменениях состояния
4 инварианты
5 пред и пост условия
Если на ровном месте появились моки, это значит что вместо проектирования у тебя кейс "а мы решили", см выше
Моки в юнит-тестах появиться не могут, потому или тесты не те, или проблема непонятная, или дизайн не тот.
Теоретически, можно взять и изобрести произвольную структуру связей. Здесь ты должен быть крут аки господь бог, что бы исследовать решение на предмет выявления разных свойств.
Требования часто неявные. Например требуется реализовать интерфейс, а дальше хоть так, хоть иначе, хоть как угодно. Фокус в том что код должен быть изначально проектироваться как тестопригодный, если ты планируешь покрывать тестами. Самый лучший вариант это функции навроде sin cos tan — тоесть, без состояния. Изменения состояния нужно протаскивать отдельной бухгалтерией.
Скажем, если ты свел решение к автомату с магазином, то стоит тестировать не все, а только функцию переходов и АПИ автомата. Тестировать все тотально смысла не имеет
Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
FH>Скажите, пожалуйста, всегда ли вы пишете юнит-тесты? На каких языках вы программируете и какие библиотеки используете для их написания? Делаете 100% покрытие кода тестами или "забиваете" на юнит-тестирование определённых частей проекта?
Важно определиться с тем какую проблему ты решаешь. Тесты это не улучшайзер, это проверка качества. Если вспомнить, что качество это степень соответствования требованиям, то сразу вопрос — какие требования ?
Вот например ты пилишь компонент, который кидает эвент ready когда его состояние из loading стало complete. Вопрос- как ты к этому пришел ?
Например было так — "мы решили что здесь будет эвент". В этом случае никаких тестов писать нет смысла.
А если ты взял какую формальную модель, спроектировал на ее основе решение, то, внезапно, есть смысл проверить, обладает ли твое решение требуемыми свойствами формальной модели
Естественно, проверяешь не все, а только ту часть, на которую полагается вызывающий код. А именно
1 поведение
2 вычисления
3 реакция — сигналы об изменениях состояния
4 инварианты
5 пред и пост условия
Если на ровном месте появились моки, это значит что вместо проектирования у тебя кейс "а мы решили", см выше
Моки в юнит-тестах появиться не могут, потому или тесты не те, или проблема непонятная, или дизайн не тот.
Теоретически, можно взять и изобрести произвольную структуру связей. Здесь ты должен быть крут аки господь бог, что бы исследовать решение на предмет выявления разных свойств.
Требования часто неявные. Например требуется реализовать интерфейс, а дальше хоть так, хоть иначе, хоть как угодно. Фокус в том что код должен быть изначально проектироваться как тестопригодный, если ты планируешь покрывать тестами. Самый лучший вариант это функции навроде sin cos tan — тоесть, без состояния. Изменения состояния нужно протаскивать отдельной бухгалтерией.
Скажем, если ты свел решение к автомату с магазином, то стоит тестировать не все, а только функцию переходов и АПИ автомата. Тестировать все тотально смысла не имеет
Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
Re: Что и как следует покрывать юнит-тестами
Здравствуйте, FrozenHeart, Вы писали:
FH>Скажите, пожалуйста, всегда ли вы пишете юнит-тесты? На каких языках вы программируете и какие библиотеки используете для их написания? Делаете 100% покрытие кода тестами или "забиваете" на юнит-тестирование определённых частей проекта?
Важно определиться с тем какую проблему ты решаешь. Тесты это не улучшайзер, это проверка качества. Если вспомнить, что качество это степень соответствования требованиям, то сразу вопрос — какие требования ?
Вот например ты пилишь компонент, который кидает эвент ready когда его состояние из loading стало complete. Вопрос- как ты к этому пришел ?
Например было так — "мы решили что здесь будет эвент". В этом случае никаких тестов писать нет смысла.
А если ты взял какую формальную модель, спроектировал на ее основе решение, то, внезапно, есть смысл проверить, обладает ли твое решение требуемыми свойствами формальной модели
Естественно, проверяешь не все, а только ту часть, на которую полагается вызывающий код. А именно
1 поведение
2 вычисления
3 реакция — сигналы об изменениях состояния
4 инварианты
5 пред и пост условия
Если на ровном месте появились моки, это значит что вместо проектирования у тебя кейс "а мы решили", см выше
Моки в юнит-тестах появиться не могут, потому или тесты не те, или проблема непонятная, или дизайн не тот.
Теоретически, можно взять и изобрести произвольную структуру связей. Здесь ты должен быть крут аки господь бог, что бы исследовать решение на предмет выявления разных свойств.
Требования часто неявные. Например требуется реализовать интерфейс, а дальше хоть так, хоть иначе, хоть как угодно. Фокус в том что код должен быть изначально проектироваться как тестопригодный, если ты планируешь покрывать тестами. Самый лучший вариант это функции навроде sin cos tan — тоесть, без состояния. Изменения состояния нужно протаскивать отдельной бухгалтерией.
Скажем, если ты свел решение к автомату с магазином, то стоит тестировать не все, а только функцию переходов(поведение) и АПИ автомата. Тестировать все тотально смысла не имеет
Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
UPD: На примере автомата — тесты функции переходов если в лоб, то это довольно хрупкие тесты. Вместо таких тестов есть вариант — четкая формальная модель автомата. Дальше покрывать тестами само поведение, здесь автомат должен быть изолирован от БД и прочих вещей.
Если автомат сделан в духе 'большой свич' то имеет смысл выразить все фокусы с переходами в виде тестов. Они будут хрупкими, но будут четко показывать, какой переход некорректный.
Собтсвенно, тесты поведения так же будут хрупкими. Например если состояние было открыто или закрыто, а стало начинаем открывать и открытие завершено и начинаем закрывать- закрытие завершено, то все тесты придется выбросить.
FH>Скажите, пожалуйста, всегда ли вы пишете юнит-тесты? На каких языках вы программируете и какие библиотеки используете для их написания? Делаете 100% покрытие кода тестами или "забиваете" на юнит-тестирование определённых частей проекта?
Важно определиться с тем какую проблему ты решаешь. Тесты это не улучшайзер, это проверка качества. Если вспомнить, что качество это степень соответствования требованиям, то сразу вопрос — какие требования ?
Вот например ты пилишь компонент, который кидает эвент ready когда его состояние из loading стало complete. Вопрос- как ты к этому пришел ?
Например было так — "мы решили что здесь будет эвент". В этом случае никаких тестов писать нет смысла.
А если ты взял какую формальную модель, спроектировал на ее основе решение, то, внезапно, есть смысл проверить, обладает ли твое решение требуемыми свойствами формальной модели
Естественно, проверяешь не все, а только ту часть, на которую полагается вызывающий код. А именно
1 поведение
2 вычисления
3 реакция — сигналы об изменениях состояния
4 инварианты
5 пред и пост условия
Если на ровном месте появились моки, это значит что вместо проектирования у тебя кейс "а мы решили", см выше
Моки в юнит-тестах появиться не могут, потому или тесты не те, или проблема непонятная, или дизайн не тот.
Теоретически, можно взять и изобрести произвольную структуру связей. Здесь ты должен быть крут аки господь бог, что бы исследовать решение на предмет выявления разных свойств.
Требования часто неявные. Например требуется реализовать интерфейс, а дальше хоть так, хоть иначе, хоть как угодно. Фокус в том что код должен быть изначально проектироваться как тестопригодный, если ты планируешь покрывать тестами. Самый лучший вариант это функции навроде sin cos tan — тоесть, без состояния. Изменения состояния нужно протаскивать отдельной бухгалтерией.
Скажем, если ты свел решение к автомату с магазином, то стоит тестировать не все, а только функцию переходов(поведение) и АПИ автомата. Тестировать все тотально смысла не имеет
Самый главный принцип — красный юнит тест должен однозначно указывать на источник ошибки. Не 'что то отвалилось' а 'метод сенд актора обнуляет бехевиор если была ошибка'
UPD: На примере автомата — тесты функции переходов если в лоб, то это довольно хрупкие тесты. Вместо таких тестов есть вариант — четкая формальная модель автомата. Дальше покрывать тестами само поведение, здесь автомат должен быть изолирован от БД и прочих вещей.
Если автомат сделан в духе 'большой свич' то имеет смысл выразить все фокусы с переходами в виде тестов. Они будут хрупкими, но будут четко показывать, какой переход некорректный.
Собтсвенно, тесты поведения так же будут хрупкими. Например если состояние было открыто или закрыто, а стало начинаем открывать и открытие завершено и начинаем закрывать- закрытие завершено, то все тесты придется выбросить.