Что посоветовать начинающему разработчику для изучения тестирования?

Что проверяют

Как вы сами тестируете код и умеете ли объяснить это простыми словами. Порядок шагов в вашем совете показывает приоритеты: с чего начинали бы вы сами и что считаете базой, а что украшением.

Как отвечать

Дайте маршрут от практики к теории, а не список книг:

• начать с юнит-тестов на чистые функции в своём же проекте: три части в теле теста (подготовка, действие, проверка), имя теста читается как утверждение о поведении;
• освоить один фреймворк, а не три сразу: xUnit или NUnit, затем параметризованные тесты и библиотека утверждений с читаемыми сообщениями;
• понять, что удобно тестируется код без статики и без создания зависимостей внутри метода. Отсюда интерфейсы, внедрение зависимостей и подмена через двойники;
• проверять поведение и границы, а не приватные методы: тест на детали реализации ломается при первом же рефакторинге;
• дальше интеграционные тесты: поднять приложение целиком фабрикой тестового хоста, базу взять в контейнере, а не подменять мокой;
• запускать тесты в конвейере сборки и смотреть покрытие как подсказку о непроверенных ветках, а не как цель.

TDD стоит пробовать, когда написание теста уже не вызывает затруднений, иначе новичок бросает на втором дне.

Где спотыкаются

Советуют начинать с браузерных автотестов. Новичок тонет в ожиданиях и плавающих падениях и делает вывод, что тесты бесполезны. Пирамида обратная: много юнит-тестов, меньше интеграционных, совсем немного сквозных.

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

Третье: выдают список курсов и книг без первого шага. Совет работает, когда из него понятно действие на сегодня: покрыть тестами один класс, который страшно трогать, и увидеть на нём пользу.