При росте системы возникает настолько большое количество мест для тестирования, что их ручной обход очень быстро становиться изнурительным. В то же время существует и в последнее время ставший популярным некий набор автоматических инструментов тестирования. Автоматические тесты позволяют программисту без затрат времени пройти тысячи тестов за несколько минут, чтобы проверить, что добавленное дополнение ничего не испортило в отношении работы системы до его внесения в код.

Довольно рано распространилось семейство автоматического тестирования классов, начиная с JUnit, предназначенного для тестирования  Java классов, однако в результате его популярности эти инструменты тестирования можно найти для классов, написанных на большинстве языков программирования. Это приложения для тестирования можно установить и запустить отдельно, хотя в тоже время возможности автоматического тестирования встроены также в большинство сред программирования. Тесты для подтверждения исправного выполнения кода пишутся по возможности маленькими и специфическими, для того, чтобы если будет известно, какой тест не прошёл проверку, то можно было по имени теста, с большой вероятностью установить, какого рода ошибка произошла, чтобы не было необходимости для этого углубляться в текст кода самого теста.

Для создания некоторой ситуации порой необходимо довольно много подготовить и с этой целью у тестов отдельно существуют подпрограммы, которые приводят систему к необходимому состоянию, чтобы можно было провести её проверку. Тестирование может потребовать общения с внешними системами. В то же время хорошей практикой считается, когда в результате тестирования  внешние каналы общения занимаются как можно реже, так как автоматические тесты запускаются довольно часто. Например, если нужно проверить, пришёл ли адекватный ответ от приложения на сообщение, посланное из системы, то не бедный клиент должен при каждом запуске теста отправлять сообщение с заказом и проверять результат, а вместе с самим тестом создаётся дополнительный модуль-эмулятор для посыла таких писем, а также отслеживания результата и его проверки. Этот дополнительный модуль уже можно будет запускать, никого не отвлекая часто и большое количество раз. В случае требовательного приложения ресурс, уходящий на создание тестов, может существенно превысить ресурс, уходящий на создание самого приложения - но в то же время это очень хорошая форма обеспечения корректности приложения. Написание мудрых тестов может в некоторых случаях перевесить возможный создаваемый приложением убыток - достаточно только привести в пример неразбериху, которая произойдет, в случае если два номера счёта в некотором банковском приложении поменяются местами.

Автоматически возможно протестировать также части приложения связанные с дизайном и веб-соединением.  Обученные с помощью программного кода и настроек роботы могут заполнить области экрана, послать данные и проверить результаты. Так можно, например, составить тесты для проверки сохранения рабочей мощности при перемене платформы, на которой система запускается, в отношении работы имеющегося приложения. При выполнении приложения в новой системе после смены платформы можно по результатам этих тестов проверить, отвечает ли новое решение тем же требованиям, что и раньше - как минимум в пределах созданных тестов. В то же время такие автоматические тесты можно считать формализованной документацией, с помощью которой заказчик и исполнитель договариваются о проделываемой работе. Исполнитель может рассчитывать, что когда приложение проходит все договоренные тесты, и ведет себя в остальной части соответственно случаю, то он может считать свою работу завершённой.