Найти тему

Принципы для создания автоматических тестов

Привет.

Уж думаю, про автоматизацию тестирования вы слышали. А слышали ли вы про принципы, на которых эта самая автоматизацию должна строится? И если в вашей компании уже внедрены тесты - то правильно ли организованы? Возможно, вы не соблюдаете какие-то принципы или даже один из них, и поэтому с вашими тестами беда? Давайте прочитаем мою свежую статью и узнаем об этом.

Автоматические тесты, которые вы пишете, должны соответствовать требованиям F.I.R.S.T. принципы. FIRTST означает, что тесты должны быть:

Fast: тесты должны быть достаточно быстрыми, чтобы вам не мешало их использовать. Как быстро? Существует исследование, в котором утверждается, что после того, как тесты проходят отметку в 30 секунд, разработчики запускают их только при глобальных изменениях, а не после каждого небольшого изменения. Итак, в идеале ваш набор тестов должен завершатся за 30 секунд. Этого невозможно добиться, если ваш тест запускается последовательно и не на 100% находится в памяти. Также необходима мощная рабочая станция.


Independent: тесты должны быть разработаны таким образом, чтобы они не разделяли какое-либо состояние программы или системы. Вы должны иметь возможность запускать тесты изолированно, в любом порядке и в любом количестве. Такая независимость делает возможным одновременное выполнение тестов. Вне зависимости друг от друга.


Repetable: вы должны иметь возможность повторять и воспроизводить тест в любой среде: локально или на сервере сборки. Фактически? это означает, что тестовая среда должна быть портативной и простой в развертывании. Здесь помогают Docker и Testcontainers.


Self validating: вы должны сразу понять состояние системы и тестов, просто просматривая список пройденных или неудачных прохождений. Прохождение тестов должны точно указывать на соответствие системы спецификации. И для этого нужна самопроверка тестов.


Timely: вы должны писать тесты непосредственно перед производством кода (TDD), потому что тесты служат критериями завершения для производственного кода, который вы пишете. Кроме того, если вы пишете тесты после производственного кода, вы можете обнаружить, что производственный код будет трудно тестировать (и, скорее всего, трудно использовать).

Есть еще такая штука как TDD, и это тема для другого поста. Может быть позже напишу.

Помните, что F.I.R.S.T. применяется не только к модульным тестам, но и ко всем другим тестам, которые создает группа доставки: интеграция, приемка или пользовательский интерфейс.