Очень странное тестирование
На HolyJS слушал доклад про тестирование на основе свойств. Мне понравилась эта техника написания юнит-тестов.
Ее суть очень проста — мы должны тестировать не работу функции на примерах, а логику ее работы.
Такая функция пройдет несколько тестов с примерами. Для 1+2, 2+1, 3+4 она работает корректно. Чтобы найти проблему, не заглядывая в код, нужно придумать еще несколько тест-кейсов. Если функция сложнее — в ней не так просто найти граничные случаи.
Если подходить к тестированию со стороны свойств функции, то нужно выделить суть операции, производимой функцией. Для сложения все довольно просто — от перестановки слогаемых сумма измениться не должна. Тогда можно сгенерировать 1000 случайных чисел и попробовать для них вызывать функцию с разным порядком аргументов. Результат для одинаковых чисел должен оставаться одинаковым.
Конечно, это свойство не дает гарантии корректности работы функции (например, она может всегда возвращать 0, или перемножать числа). Поэтому нужно найти еще несколько свойств и написать тесты и для них.
Искать свойства сложно. Но хорошо написанные тесты на основе свойст дают больше уверенности в корректности функции, чем хорошо написанные тесты на основе примеров.
Для JavaScript есть классная бибилиотека — fast-check. Генерирует случайные наборы данных в заданных диапозонах, интегрируется со всеми популярными тест раннерами, умеет еще много чего.
#тестирование
На HolyJS слушал доклад про тестирование на основе свойств. Мне понравилась эта техника написания юнит-тестов.
Ее суть очень проста — мы должны тестировать не работу функции на примерах, а логику ее работы.
function sum(a, b) {
if (a === 3 && b === 4) {
return 7
}
return 3
}Такая функция пройдет несколько тестов с примерами. Для 1+2, 2+1, 3+4 она работает корректно. Чтобы найти проблему, не заглядывая в код, нужно придумать еще несколько тест-кейсов. Если функция сложнее — в ней не так просто найти граничные случаи.
Если подходить к тестированию со стороны свойств функции, то нужно выделить суть операции, производимой функцией. Для сложения все довольно просто — от перестановки слогаемых сумма измениться не должна. Тогда можно сгенерировать 1000 случайных чисел и попробовать для них вызывать функцию с разным порядком аргументов. Результат для одинаковых чисел должен оставаться одинаковым.
Конечно, это свойство не дает гарантии корректности работы функции (например, она может всегда возвращать 0, или перемножать числа). Поэтому нужно найти еще несколько свойств и написать тесты и для них.
Искать свойства сложно. Но хорошо написанные тесты на основе свойст дают больше уверенности в корректности функции, чем хорошо написанные тесты на основе примеров.
Для JavaScript есть классная бибилиотека — fast-check. Генерирует случайные наборы данных в заданных диапозонах, интегрируется со всеми популярными тест раннерами, умеет еще много чего.
#тестирование
Одержимость тестированием
Ниже речь пойдет только о веб-приложениях, которые легко и безболезненно деплоить.
В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через QA;
+ когда все таски сделаны, собираем контейнер версии, которую собираемся релизить;
+ QA делают регрессионное тестирование;
+ катим в продакшн;
+ QA делают смоук-тест.
Короче, мы много заморачивались на тестировании, старались избежать даже самых мелких багов на продакшене.
В Aviasales все устроено совсем иначе. Разработчик делает таску, другой разработчик ее тестирует и заодно смотрит код, после — катим таску на продакшн, потом ещё 10 минут смотрим за фоном ошибок и метриками.
В такой парадигме код доставляется клиентам сильно быстрее. А самое удивительное, что и багов больше не стало. Мне подход «смелых релизов» нравится больше.
#кейс #тестирование
Ниже речь пойдет только о веб-приложениях, которые легко и безболезненно деплоить.
В Самокате у нас был примерно такой флоу релиза:
+ планируем версию, накидываем таски, которые в неё попадут;
+ каждая таска проходит через QA;
+ когда все таски сделаны, собираем контейнер версии, которую собираемся релизить;
+ QA делают регрессионное тестирование;
+ катим в продакшн;
+ QA делают смоук-тест.
Короче, мы много заморачивались на тестировании, старались избежать даже самых мелких багов на продакшене.
В Aviasales все устроено совсем иначе. Разработчик делает таску, другой разработчик ее тестирует и заодно смотрит код, после — катим таску на продакшн, потом ещё 10 минут смотрим за фоном ошибок и метриками.
В такой парадигме код доставляется клиентам сильно быстрее. А самое удивительное, что и багов больше не стало. Мне подход «смелых релизов» нравится больше.
#кейс #тестирование